Secure Code Review Checklist for Pull Requests

Code review is the cheapest place to catch security bugs. You do not need to be a security expert; you need to know which questions to ask. Use this checklist on pull requests that touch endpoints, data access, authentication or external input.

Authorisation

• Does every new or changed endpoint check that the user may perform this action?
• Are database queries scoped to the current user or tenant?
• Can a user change an ID in the request to access someone else's object?
• Are admin-only operations protected on the server, not just hidden in the UI?
• Are there tests proving another user cannot access this resource?

Input handling

• Is all external input validated with a schema: request bodies, query strings, headers, files and webhooks?
• Are unknown fields rejected, preventing mass assignment?
• Are SQL queries parameterised, with no string concatenation?
• Are shell commands avoided, or called with argument arrays?
• Are file paths built safely, without user-controlled traversal?
• Are URLs fetched by the server validated against SSRF?

Output handling

• Is user content rendered with framework escaping, without raw HTML insertion?
• If HTML is allowed, is it sanitised?
• Do API responses return only the fields the client needs?
• Do error messages avoid leaking stack traces, queries or internal details?

Authentication and sessions

• Do changes to login, signup, reset or MFA preserve rate limits and uniform errors?
• Are tokens validated fully, including signature, expiry and audience?
• Are sessions invalidated where they should be, such as on password change?

Secrets and configuration

• Are there any hardcoded keys, passwords or tokens?
• Are new secrets loaded from the secrets manager?
• Are debug flags, verbose logging or test endpoints disabled in production?
• Do new cloud resources follow least privilege and private-by-default settings?

Dependencies

• Is each new dependency necessary, maintained and reputable?
• Are versions pinned in the lockfile?

Logging

• Are security-relevant events logged, such as permission changes and failed authorisation?
• Are secrets and sensitive personal data kept out of logs?

Business logic

• Can this feature be abused by repeating, reordering or skipping steps?
• Are limits, quotas and prices enforced on the server?
• Are concurrent requests handled atomically?

Reviewing AI-generated code

AI-generated code deserves the same checklist, with extra attention to authorisation, which assistants frequently omit, and to queries that load objects by ID without scoping.

A short version for every PR

1. Who can call this, and is that enforced?
2. What input does it accept, and is it validated?
3. What does it return, and is that too much?
4. Does it add secrets, dependencies or infrastructure?

Back reviews with testing

Reviews miss things, especially across many endpoints. SecurityInfinity tests the running application after each release, catching authorisation and injection issues that slipped through review. Start free.

Frequently asked questions

Should every PR get a security review?

Every PR gets normal review with the short checklist. PRs touching authentication, payments, permissions or data access deserve deeper attention.

Can SAST replace manual security review?

No. SAST catches patterns, but reviewers catch missing authorisation and logic issues that tools cannot see.

How do I train developers in secure review?

Use real findings from your own pentests and bug reports as examples. They are more memorable than generic training.