Application Security

"Authn says who; authz says what; sanitization says never trust input." [INFERENCE]

TL;DR

Implements application-level security controls: authentication (OAuth/SAML/IAM), RBAC authorization, input validation/sanitization, CORS, HTTP security headers, rate limiting, and audit/testing. Hands-on counterpart to strategic threat-modeling and to Claude-tool permissions (tool-permission-policy). [EXPLICIT]

When to use

• Designing RBAC (role hierarchy, scope binding, policy composition). [EXPLICIT]
• Hardening inputs against XSS/injection with context-aware escaping. [EXPLICIT]
• Configuring CORS + CSP/HSTS/security headers correctly. [EXPLICIT]
• Adding rate limiting (token bucket / sliding window) and DDoS guards. [EXPLICIT]
• Standing up audit logging and security testing (SAST/DAST) gates. [EXPLICIT]

Sub-capabilities (resource map)

Procedure

1. Identify the control the request needs; open its references/ playbook. [EXPLICIT]
2. Default-deny: authorization denies unless explicitly granted; inputs untrusted until validated. [DOC]
3. Sanitize at the boundary, context-aware (HTML/URL/SQL/shell), never by blocklist alone. [DOC]
4. Set headers + CORS restrictively; allowlist origins, no wildcard with credentials. [DOC]
5. Verify with security tests and an audit-log review before ship. [EXPLICIT]

Quality Criteria

• Authorization is default-deny with least privilege. [DOC]
• Inputs validated/sanitized context-aware at the boundary. [DOC]
• CORS allowlists origins; no * with credentials; CSP present. [DOC]
• Rate limits protect auth and write endpoints. [INFERENCE]
• Claims evidence-tagged. [EXPLICIT]

Anti-Patterns

• Blocklist-only sanitization (bypassable). [DOC]
• Access-Control-Allow-Origin: * with Allow-Credentials: true (spec-invalid + unsafe). [DOC]
• Authorization checks on the client only. [DOC]

Contract

• Aceptación: authz default-deny; input sanitizado context-aware; CORS/headers restrictivos; rate-limit en auth/escritura; audit + tests pasados. [EXPLICIT]
• Límites: controles a nivel aplicación; no reemplaza el threat-modeling estratégico ni los permisos de tools de Claude (tool-permission-policy). [EXPLICIT]
• Casos borde: claims de auth desincronizados; CORS preflight fallando por headers no allowlisted. [INFERENCE]
• Supuestos: stack web con capa de auth disponible. [SUPUESTO]
• Trade-off: controles estrictos añaden fricción/latencia a cambio de superficie de ataque reducida. [EXPLICIT]

Related Skills

• tool-permission-policy — Claude tool permissions (a different, agent-side layer). [EXPLICIT]
• firebase-platform — Firebase security rules as a platform-specific authz surface. [EXPLICIT]
• cicd-release-engineering — security gates (SAST/DAST) in the pipeline. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · assets/ recursos estáticos.