Security Checklist

Purpose

This is a reference checklist, not an agent. Any agent — code-simplifier, test-writer, verify-app, or the main session — can consult this when they encounter security-relevant code. The dedicated security-reviewer agent does deeper analysis; this checklist catches the obvious issues.

Quick Scan (30 seconds)

Before committing any code that handles user input, authentication, or external data, check these five things:

1. No hardcoded secrets — grep for API keys, passwords, tokens, connection strings
2. Input is validated — user input goes through validation before use
3. Queries are parameterized — no string concatenation in SQL/NoSQL queries
4. Output is escaped — user content is not rendered as raw HTML
5. Auth is checked — protected endpoints have authentication middleware

If any fail, stop and fix before committing.

OWASP Top 10 Reference

A01: Broken Access Control

• Every endpoint checks authentication AND authorization
• Users cannot access other users' resources by changing IDs in URLs
• File paths from user input are sanitized (no path traversal)
• CORS is configured to allow only expected origins
• Directory listing is disabled on static file servers

A02: Cryptographic Failures

• Passwords hashed with bcrypt, scrypt, or argon2 — never MD5/SHA for passwords
• Sensitive data encrypted at rest (PII, payment info)
• HTTPS enforced in production — no mixed content
• API keys and secrets stored in environment variables, not source code
• Random values use crypto-secure generators, not Math.random()

A03: Injection

• SQL: parameterized queries or ORM — never string concatenation
• NoSQL: no user input in $where, $regex operators
• OS commands: use dedicated libraries, not shell execution with user input
• LDAP: parameterized queries if applicable
• Template engines: auto-escaping enabled by default

A04: Insecure Design

• Rate limiting on authentication endpoints
• Account lockout after repeated failures
• No sensitive data in URLs or query parameters
• Session tokens regenerated after login
• Passwords have minimum complexity requirements

A05: Security Misconfiguration

• Debug mode disabled in production
• Default credentials changed
• Security headers set: X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security
• Error messages don't expose stack traces or internal details to users
• Unused features and endpoints removed

A06: Vulnerable Components

• Dependencies up to date — no known CVEs
• Lock files committed (package-lock.json, yarn.lock, etc.)
• Dependency audit clean: npm audit, pip audit, cargo audit
• No abandoned packages with no maintenance

A07: Authentication Failures

• Passwords not stored in plaintext
• JWT tokens validated on every request (signature, expiry, issuer)
• Session management uses secure cookies (HttpOnly, Secure, SameSite)
• Password reset tokens are single-use and time-limited
• Multi-factor authentication available for sensitive operations

A08: Data Integrity Failures

• Deserialization of user input uses safe libraries
• CI/CD pipelines verify integrity of dependencies
• Software updates use signed packages

A09: Logging Failures

• Security events are logged (login attempts, access denied, input validation failures)
• Logs do NOT contain passwords, tokens, or PII
• Log injection is prevented (user input in logs is sanitized)
• Alerts configured for suspicious patterns

A10: Server-Side Request Forgery (SSRF)

• URLs from user input are validated against an allowlist
• Internal network addresses blocked (127.0.0.1, 10.x, 169.254.x, etc.)
• DNS rebinding protection if URL resolution is involved
• Response from fetched URLs is not returned raw to the user

When to Consult This

• Writing code that handles user input
• Implementing authentication or authorization
• Adding new API endpoints
• Handling file uploads
• Integrating with external services
• Updating dependencies
• Before any release

Common False Positives

Not everything is a security issue:

• Test credentials in test files (clearly marked as test-only)
• Public API keys that are designed to be public (e.g., Stripe publishable key)
• SHA-256/MD5 used for checksums or cache keys (not for password hashing)
• Environment variables in .env.example (templates, not real secrets)
• Self-signed certificates in development environments