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 — STRIDE methodology, risk assessment process, trust boundaries
- Authentication and Authorization — JWT, session-based, OAuth, RBAC, ABAC, IDOR protection
- API Security — OWASP API Security Top 10, object-level authorization, rate limiting, SSRF prevention, security testing
- Input Validation — SQL injection, XSS, command injection, path traversal, Zod validation, file upload security
- Data Protection — Password hashing (argon2id/bcrypt), AES-256-GCM encryption, secrets management
- Secure Configuration — Security headers, CORS, Express hardening, rate limiting
- Supply Chain Security — SBOM generation, dependency scanning, CI/CD hardening, artifact signing
- Monitoring and Compliance — Audit logging, error handling, GDPR/HIPAA/SOC2/PCI-DSS, troubleshooting
