application-security

What this skill does

# Security

Security is built-in, not bolted-on. Every feature, endpoint, and data flow must consider security implications.

## OWASP Top 10 (2025)

| #   | Vulnerability                      | Prevention                                      |
| --- | ---------------------------------- | ----------------------------------------------- |
| 1   | Broken Access Control              | Verify permissions server-side, default deny    |
| 2   | Security Misconfiguration          | Secure defaults, remove unused features         |
| 3   | Software Supply Chain Failures     | SBOM, dependency scanning, signed builds        |
| 4   | Cryptographic Failures             | Use TLS, hash passwords (argon2id), encrypt PII |
| 5   | Injection                          | Parameterized queries, input validation         |
| 6   | Insecure Design                    | Threat modeling, security requirements          |
| 7   | Authentication Failures            | Strong passwords, MFA, secure session mgmt      |
| 8   | Software or Data Integrity         | Verify dependencies, sign releases              |
| 9   | Logging and Alerting Failures      | Log security events, set up alerts              |
| 10  | Mishandling Exceptional Conditions | Fail securely, generic errors to clients        |

## Security Principles

| Principle          | Rule                                                      |
| ------------------ | --------------------------------------------------------- |
| Defense in Depth   | Multiple layers: firewall, auth, authz, encryption, audit |
| Least Privilege    | Minimum permissions needed, nothing more                  |
| Zero Trust         | Never trust, always verify. Assume breach.                |
| Secure by Default  | HTTPS, strict passwords, secure cookies out of the box    |
| Fail Securely      | Access denied on error, no internal details to users      |
| Validate on Server | Client validation is UX, server validation is security    |

## Pre-Deployment Checklist

| Area          | Requirements                                                        |
| ------------- | ------------------------------------------------------------------- |
| Passwords     | Hashed with argon2id (preferred) or bcrypt (12+ rounds)             |
| Tokens        | JWT with EdDSA/ES256, 15min access / 7d refresh, httpOnly cookies   |
| Sessions      | HttpOnly, Secure, SameSite=Strict cookies                           |
| Rate Limiting | Auth endpoints: 5 attempts/15min                                    |
| Authorization | All routes check auth server-side, default deny                     |
| Input         | Validated with schema (Zod), parameterized SQL                      |
| Uploads       | Whitelist types, enforce size limits                                |
| Secrets       | No secrets in code or VCS                                           |
| Headers       | CSP (with nonces), HSTS, Permissions-Policy, X-Content-Type-Options |
| CORS          | Configured restrictively                                            |
| Encryption    | PII encrypted at rest (AES-256) and in transit (TLS 1.3)            |
| Logging       | Audit logging for security events                                   |
| Dependencies  | SBOM generated, `npm audit` clean, Dependabot enabled               |

## Threat Modeling (STRIDE)

| Threat                 | Category        | Key Mitigations                                        |
| ---------------------- | --------------- | ------------------------------------------------------ |
| Spoofing               | Authentication  | MFA, strong passwords, JWT with short expiry           |
| Tampering              | Integrity       | Input validation, HTTPS/TLS, signed tokens             |
| Repudiation            | Accountability  | Audit logging, digital signatures                      |
| Info Disclosure        | Confidentiality | Encryption, least privilege, secret management         |
| Denial of Service      | Availability    | Rate limiting, input validation, CDN/DDoS protection   |
| Elevation of Privilege | Authorization   | Authz checks on every request, ABAC, permission audits |

## Risk Levels

| Level    | Action                    |
| -------- | ------------------------- |
| Critical | Immediate action required |
| High     | Address before launch     |
| Medium   | Address post-launch       |
| Low      | Monitor, may accept risk  |

## Compliance Overview

| Framework | Scope              | Key Requirements                                                   |
| --------- | ------------------ | ------------------------------------------------------------------ |
| GDPR      | EU data subjects   | Consent, data subject rights, breach notification (72h), DPIA      |
| HIPAA     | US healthcare data | PHI encryption, RBAC, audit logs, BAA with providers               |
| SOC 2     | SaaS customer data | Security policies, MFA, encryption, incident response              |
| PCI-DSS   | Credit card data   | Use payment processor (Stripe), tokenization, network segmentation |

## Anti-Patterns

| Anti-Pattern                                  | Fix                                              |
| --------------------------------------------- | ------------------------------------------------ |
| Security as afterthought                      | Integrate from design phase                      |
| Client-side authorization                     | Always verify permissions server-side            |
| Trusting client data (e.g., userId from body) | Get user ID from authenticated session           |
| Rolling your own crypto                       | Use proven libraries (argon2, bcrypt, libsodium) |
| Compliance = security                         | Compliance is the minimum; security is ongoing   |
| Verbose error responses                       | Generic messages to clients, details server-side |

## Common Mistakes

| Mistake                                                       | Correct Pattern                                                     |
| ------------------------------------------------------------- | ------------------------------------------------------------------- |
| Performing authorization checks only on the client side       | Always verify permissions server-side; client checks are UX only    |
| Trusting user-supplied IDs from request body (e.g., userId)   | Derive user identity from the authenticated session or token        |
| Rolling custom cryptography instead of using proven libraries | Use argon2id, bcrypt, or libsodium for all cryptographic operations |
| Treating compliance certification as equivalent to security   | Compliance is the minimum bar; security requires ongoing review     |
| Returning verbose error messages with stack traces to clients | Show generic messages to clients; log details server-side only      |

## Delegation

- **Scan codebase for OWASP Top 10 vulnerabilities and insecure patterns**: Use `Explore` agent to search for SQL injection, XSS, and hardcoded secrets
- **Implement authentication, authorization, and security headers end-to-end**: Use `Task` agent to configure JWT, RBAC, CSP, HSTS, and rate limiting
- **Design a threat model and security architecture for new features**: Use `Plan` agent to apply STRIDE methodology and map trust boundaries

> For database-layer security (RLS policies, Postgres/Supabase hardening, audit trails), use the `database-security` skill. For AI/LLM security (prompt injection defense, agentic zero-trust, MCP tool hardening), use the `secure-ai` skill.

## References

- [Threat Modeling](references/threat-modeling.md) — STRIDE methodology, risk assessment process, trust boundaries
- [Authentication and Authorization](references/auth.md) — JWT, session-based, OAuth, RBAC, ABAC, IDOR protection
- [API Security](references/api-security.md) — OWASP API Security Top 10, object-level authorization, rate limiting, SSRF prevention, security testing
- [Input Validat