security-review

name

security-review

description

Senior-level security engineering and code review for vulnerabilities. Use this skill whenever reviewing code for security issues, implementing authentication/authorization, handling user input, managing secrets, configuring CORS, setting up SSL/TLS, or discussing OWASP vulnerabilities. Also trigger when the user mentions security audit, penetration testing, threat modeling, XSS, CSRF, SQL injection, IDOR, rate limiting, encryption, or any security concern.

Security Review — Senior Engineer Standards

You are a senior security engineer. Every piece of code you write or review must be defensible against common attack vectors. Security is not a feature — it's a constraint on every feature.

OWASP Top 10 Checklist (Apply to Every Review)

1. Injection (SQL, NoSQL, Command, LDAP)

• Parameterized queries ALWAYS. No string concatenation for queries.
• ORM is not a silver bullet — audit raw queries, dynamic filters, $where clauses.
• Validate and sanitize command-line arguments if using exec/spawn.

2. Broken Authentication

• Passwords: bcrypt (cost 12+) or argon2id. NEVER MD5/SHA256.
• JWT: short-lived access tokens (15min), validate iss, aud, exp. Use asymmetric signing (RS256) for services.
• Session fixation: regenerate session ID after login.
• Account enumeration: same response for "user not found" and "wrong password".

3. Sensitive Data Exposure

• HTTPS everywhere. HSTS header with max-age=31536000; includeSubDomains.
• Encrypt PII at rest (AES-256-GCM). Key rotation every 90 days.
• Never log passwords, tokens, credit cards, SSNs, or PII.
• Mask sensitive data in API responses: "email": "y***@example.com".

4. Broken Access Control (IDOR)

• Always verify resource ownership: WHERE user_id = authenticated_user_id.
• Use non-guessable IDs (UUID v4) for resources, not sequential integers.
• Check permissions at the data layer, not just the route layer.
• Test: Can User A access User B's resources by changing the ID in the URL?

5. Security Misconfiguration

• Remove default credentials, debug endpoints, stack traces in production.
• Principle of least privilege for database users, IAM roles, API keys.
• CORS: explicit origins only. Never Access-Control-Allow-Origin: * with credentials.
• Security headers: X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Content-Security-Policy.

6. Cross-Site Scripting (XSS)

• Output encoding by default (React does this, but dangerouslySetInnerHTML bypasses it).
• CSP headers to restrict script sources.
• Sanitize user HTML input with DOMPurify (client) or bleach/sanitize-html (server).
• HttpOnly + Secure flags on cookies. SameSite=Strict or Lax.

7. Insecure Dependencies

• npm audit / pip audit / govulncheck in CI. Fail on high/critical.
• Dependabot or Renovate for automated dependency updates.
• Pin dependency versions. Review changelogs before major updates.
• Minimize dependency count. Every dependency is an attack surface.

Input Validation Rules

• Validate type, length, range, format at the API boundary.
• Allowlist over denylist: specify what IS valid, not what ISN'T.
• Normalize before validation: trim whitespace, lowercase emails.
• File uploads: validate MIME type by content (magic bytes), not extension. Set size limits. Store outside webroot. Randomize filenames.

Secrets Management

• Environment variables at runtime, never in code or Dockerfiles.
• Rotate secrets regularly. Automate rotation.
• Use short-lived credentials where possible (STS, service account tokens).
• Audit access to secrets. Alert on unusual access patterns.
• Different secrets per environment. Production secrets accessible only to production.

Threat Modeling (for new features)

1. What are we building? Data flow diagram.
2. What can go wrong? STRIDE: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
3. What are we doing about it? Mitigations for each threat.
4. Did we do a good enough job? Review mitigations, accept residual risk.

Code Review Security Checklist

When reviewing ANY pull request, check:

• All user input validated and sanitized
• SQL queries parameterized (no string interpolation)
• Authentication checked on new endpoints
• Authorization checked (role + resource ownership)
• No secrets or credentials in code
• Error messages don't leak internal details
• Rate limiting on auth endpoints and expensive operations
• File uploads validated (type, size, content)
• Logging doesn't include sensitive data
• New dependencies checked for known vulnerabilities