A secure coding checklist is useful only if it catches the things teams actually miss. The point is not to be exhaustive. The point is to make dangerous mistakes hard to overlook during review.
Before merge
- Is access control enforced on the server?
- Are inputs validated and encoded in the correct context?
- Are secrets, tokens, and credentials kept out of code and logs?
- Are dependencies current and pinned where appropriate?
- Do tests cover security-sensitive paths and edge cases?
Design review
- Does the workflow allow abuse, replay, or privilege escalation?
- Are failure states safe by default?
- Can a user act on another user's data by guessing an identifier?
- Does the system reveal too much detail in errors or logs?
Implementation review
- Use parameterized queries and safe APIs for commands and templates.
- Prefer allowlists over blocklists for security-sensitive input.
- Check authorization at the point of use, not only at the edge.
- Handle nulls, timeouts, and downstream failures explicitly.
- Verify artifacts, updates, and build outputs where trust matters.
Release review
- Confirm logging and alerting exist for suspicious behavior.
- Check that security headers and environment settings are correct.
- Make sure rollback paths are tested.
- Verify that observability tells you when the app is being abused.
The best checklist is short enough to use on every meaningful change and specific enough to catch recurring mistakes. If a reviewer cannot apply it in two minutes, it is too long.