Most code review focuses on correctness and style. A security-aware review adds a specific, narrower set of questions — and it doesn't require a dedicated security engineer to ask them.
Input handling
- Is all external input (query params, request bodies, headers, file uploads) validated before use?
- Are database queries parameterized, not string-concatenated?
- Is user-controlled input ever used to construct file paths, shell commands, or URLs without sanitization?
Authentication and authorization
- Does this endpoint check the user is authenticated?
- Separately — does it check the authenticated user is authorized for this specific resource? (This is the gap that's missed far more often than the first check.)
- Are authorization checks performed server-side, not just hidden in the client UI?
Secrets and configuration
- Are any credentials, API keys, or tokens hardcoded, even for "temporary" testing?
- Is sensitive configuration read from a secret manager or environment, not committed to the repo?
Data exposure
- Does an API response include more fields than the client actually needs (over-fetching that leaks internal fields)?
- Are error messages returned to the client free of internal details (stack traces, database errors, file paths)?
Dependencies
- Does this PR introduce a new dependency? If so, is it actively maintained and reasonably well-scoped for what it's used for?
Logging
- Are sensitive values (passwords, tokens, full credit card numbers) excluded from logs?
- Is there enough logging to reconstruct what happened if this code path is involved in an incident later?
Making this sustainable
Trying to apply this full list to every PR creates fatigue and gets skipped under deadline pressure. Reserve the full checklist for PRs touching auth, data access, or external input — and let lighter-weight automated checks (SAST, dependency scanning) cover the rest continuously.
The value of a checklist like this isn't the list itself — it's training reviewers to ask "who's allowed to see this" and "what happens with bad input" as a reflex, not an afterthought.