A security-focused code review checklist for changes at trust boundaries

Goal

Catch the security defects that a general review skips because they are correct code doing the wrong thing: a missing authorization check, an unescaped output, a URL fetched from user input.

Prerequisites

A change description that names the trust boundaries touched, a general review already done for design and correctness, and the linked wiki articles for the details of each control. The OWASP Code Review Guide (cited) is the long-form reference for the same activity.

Steps

1. Decide whether the checklist applies: does the change read input from outside the process, change who may do what, touch a database or filesystem, make outbound requests, handle credentials or keys, or add a dependency? If none, stop.
2. Input: for each new entry point, find where the data is validated (type, length, allowlist) and where it is used; every use that builds a query, command, path, URL or markup must go through parameterisation or encoding, not string concatenation.
3. Authentication and sessions: any new endpoint is behind the same authentication as its siblings; login, reset, MFA and token code regenerates identifiers and expiries where the existing articles say so.
4. Authorization: for each object accessed by an identifier from the request, locate the check that the current principal may access that object, not just the endpoint. Look for the missing check on the second path (bulk, export, admin, webhook).
5. Data access and storage: queries parameterised; new columns with personal data classified and covered by retention; files written under a random name in a non-executable location.
6. Outbound: any URL built from input goes through the SSRF allowlist; redirects target only relative paths or listed hosts; XML, YAML and native serialisation are parsed with the safe loader.
7. Secrets and configuration: no literal credentials, no secrets in logs or error messages, new configuration fails closed when absent.
8. Dependencies: a new package has a reason, a pinned version and a maintained upstream; a lockfile change is reviewed for unexpected packages.
9. Logging and errors: security-relevant actions produce an audit event; error responses expose no stack traces or internal hosts.
10. Write findings as questions with a pointer to the relevant article; block the merge only on items from steps 2, 4 and 6, the ones an attacker reaches first.

Expected result

Boundary-touching changes get a consistent second look; reviewers spend the security attention where it pays and skip it elsewhere.

Limits and test basis

A proposal, not a measured practice. The list finds omissions, not logic flaws in business rules, which need threat modelling. Applying it to every change dilutes it; applying it only when the author flags a boundary depends on the author noticing.