Secure Code Review: A Checklist for Everyday Pull Requests

Before reading line by line, ask five questions about the change:

1. Who can trigger this code? Anonymous users, signed-in users, admins, another service?
2. What data does it touch? Customer data, credentials, payment details, logs?
3. What does it trust? Anything from a request, a file, a webhook or a third-party API is untrusted until validated.
4. What changes if it fails? Does it fail open (grants access) or closed (denies)?
5. What did it add? New dependencies, new endpoints, new permissions, new environment variables.

If a pull request is too large to answer these, ask the author to split it. Large diffs invite skimming, while five small ones get read.

Broken access control is the flaw reviewers most often miss, because the code works for the happy path. Check:

• Every endpoint has an authorization check, not only a login check. Being signed in doesn't mean being allowed.
• Object-level checks. When a request names an ID, the code verifies the caller owns or may access that record, not just that the ID exists.
• Tenant boundaries. Queries include the tenant or organization filter, and it comes from the session, not the request body.
• Role logic is centralized. Scattered role checks drift. Prefer a shared policy function.
• Sensitive actions are re-verified. Changing email, exporting data or altering permissions may need fresh confirmation.

A quick test: ask 'what happens if I change this ID to another customer's?'

Trace untrusted data from where it enters to where it's used:

• Queries. Parameterized queries or an ORM's safe methods, never string-built SQL or shell commands.
• Output. Data rendered into pages is escaped by the framework. Look closely at anywhere raw HTML is inserted.
• File and URL handling. Uploaded filenames, paths and user-supplied URLs are validated. Server-side requests to user-provided addresses can reach internal services.
• Deserialization and templates. Untrusted data isn't fed into unsafe parsers or template engines.
• Secrets. No keys, tokens or passwords in code, tests, config samples or logs. If one appears, treat it as leaked and rotate it.
• Cryptography. Standard libraries, not homemade schemes. Passwords use a slow, salted hashing function, and random tokens come from a secure generator.

Check what the change brings in and what it leaves behind:

1. New packages. Is it maintained, is it needed, and does its license fit? A scanner such as Snyk or GitHub Advanced Security can help surface known vulnerabilities and license problems during review. Confirm in a demo how each fits your repositories and workflow.
2. Fix timelines. CISA's federal directives required agencies to patch critical vulnerabilities on internet-facing systems within 15 days and high ones within 30¹. Set your own deadlines and enforce them in review.
3. Errors. Messages shown to users don't reveal stack traces, queries or internal names.
4. Logs. Security events (login failures, permission changes) are logged, and sensitive values (passwords, tokens, full card numbers) never are.
5. Configuration. Debug modes and permissive settings aren't shipped to production.

Checklists that live in a wiki are ignored. Put this one where reviewers work:

• Add a short security section to the pull request template with the five questions and the checks above as tick boxes.
• Automate the mechanical checks: secret scanning, dependency scanning and static analysis on every pull request, so humans review logic.
• Require a second reviewer for changes to authentication, payments and infrastructure.
• Keep a short list of past findings, so reviewers learn from real mistakes.

Code written with AI assistants deserves the same scrutiny, and often more; the AI-generated code security review checklist covers what to look for. For help choosing scanners, see the scanner comparison.