Most code review catches bugs and style issues. Very little of it catches security defects, because the reviewer is reading for "does this work?" rather than "how could this be abused?" — and because the things that make code insecure are often invisible in a diff. A missing authorization check looks like normal code. A SQL query built with string concatenation looks like a query. The absence of a validation step is, by definition, nothing to see. Secure code review is a distinct discipline layered on top of normal review, and it works best as a checklist the reviewer runs through deliberately rather than a vibe they hope to develop. This is that checklist, organized by the categories where real vulnerabilities cluster — closely tracking the OWASP Top 10.
Access control and authorization
Broken access control is consistently the most prevalent serious web vulnerability, and it's almost always a review-time miss rather than a scanner catch, because whether a given user should be able to perform an action is business logic no static tool understands.
- Does every state-changing endpoint verify the caller is authorized for this specific resource, not just authenticated?
- Are object identifiers in requests checked against the caller's ownership, or can a user swap an ID and access someone else's data (IDOR)?
- Are authorization checks enforced server-side, never relying on the UI hiding a button?
- Do new admin or privileged routes reuse the established authorization middleware, or roll their own?
Input handling and injection
Any data crossing a trust boundary — request bodies, headers, query params, uploaded files, messages from other services — is untrusted until validated.
- Are database queries parameterized, with no string concatenation of user input into SQL, NoSQL, or ORM raw queries?
- Is user input that reaches a shell,
eval, template engine, or deserializer treated as hostile? - Is output encoded for its context (HTML, attribute, JS, URL) to prevent XSS, rather than filtered on input?
- Are file uploads validated by content, size, and stored outside the web root with generated names?
Secrets and configuration
- Any hardcoded credentials, API keys, tokens, or private keys in the diff — including in tests and comments?
- Are secrets read from a secret manager or environment, never committed?
- Is verbose error output or stack-trace leakage disabled in production paths?
- Are new configuration flags secure by default (TLS on, debug off, permissive CORS avoided)?
Cryptography and authentication
- Are passwords hashed with a modern, slow algorithm (argon2, bcrypt, scrypt) — never MD5/SHA-1 or plain?
- Is randomness from a cryptographically secure source for tokens, session IDs, and nonces?
- Are session tokens rotated on privilege change and invalidated on logout?
- No custom crypto — is the code using vetted library primitives rather than hand-rolling?
Dependencies and supply chain
The diff isn't just the code your teammate wrote — it's every package a new import drags in.
- Does a new dependency come from a reputable, maintained source, and is it pinned in the lockfile?
- Has the addition been checked for known CVEs, and is the vulnerable code path actually reachable?
- Are third-party CI actions and base images pinned to immutable references?
Business logic and error handling
- Can a workflow be completed out of order, replayed, or short-circuited (e.g., checkout without payment)?
- Are numeric limits, quantities, and monetary values validated against negative and overflow values?
- Do failures fail closed (deny) rather than open (allow) on the security-relevant path?
- Is security-relevant activity logged with enough context to investigate, without logging secrets or PII?
How to scale review without burning out reviewers
No human runs this full checklist on every PR at modern shipping velocity, and they shouldn't have to. The sustainable model is a division of labor: automate the mechanical categories and reserve human attention for the judgment calls. SAST and software composition analysis handle injection patterns, hardcoded secrets, and vulnerable dependencies deterministically on every pull request. AI review handles the middle ground — Griffin AI reads the diff for authorization gaps, unsafe deserialization, and logic flaws that pattern-matchers miss, and explains the risk in-line so the human reviewer starts from an informed position. That leaves reviewers free to focus on the genuinely contextual question tools can't answer: should this user be able to do this?
Reviewer quick-reference
| Category | Highest-value question |
|---|---|
| Access control | Is this user authorized for this resource, server-side? |
| Injection | Is untrusted input parameterized / encoded for its sink? |
| Secrets | Anything credential-shaped hardcoded in the diff? |
| Crypto/auth | Modern hashing, secure randomness, no custom crypto? |
| Dependencies | New package vetted, pinned, reachable-CVE-checked? |
| Logic | Can the flow be replayed, reordered, or failed open? |
How Safeguard Helps
Safeguard makes secure review a default property of the pull request rather than a heroic effort. Griffin AI posts a security-focused review on every PR — flagging authorization gaps, injection sinks, and unsafe patterns with plain-language reasoning — while reachability-aware SCA catches vulnerable dependencies the diff pulls in. When a fix is mechanical, auto-fix proposes the change directly in the PR so review and remediation happen in the same place. Teams migrating from a heavier SAST tool often compare the developer experience in our Safeguard vs Checkmarx comparison.
Add automated security review to your pull requests free at app.safeguard.sh/register, or explore the review and policy docs at docs.safeguard.sh.