Secure Code Review Checklist: Auth, Secrets, Input

Most security flaws that reach production sit in four places a reviewer can check line by line: how the code authenticates callers, how it decides what they may do, how it handles secrets, and how it treats input. This template is a ready-to-use checklist for those four areas, plus the error handling and logging that make failures visible. Each item is phrased as a yes or no question, tied to an OWASP ASVS 5.0 requirement and, where one exists, a CWE weakness from the 2025 CWE Top 25. It is for developers, reviewers and security champions doing pull request or baseline reviews. How to run a review programme (triage, workflow, tooling and gates) is covered in the Secure Code Review Guide; this page is the artefact a reviewer fills in.

How to use this template

Pick the sections that apply: a change that touches only a data export needs sections 3, 5 and 6; a new login flow needs all of them. Mark the rest "not in scope for this change" with a reason.
Answer every applicable item Yes, No or N/A: any "No" becomes a finding in section 8 with a severity and an owner.
Diff or baseline: for a pull request (diff-based review), check the items against the changed code and the controls it relies on; for a baseline review of a whole application, work through every section in order. The OWASP Secure Code Review Cheat Sheet describes both modes.
Tools first, people second: run static analysis and secret scanning before the manual review so the reviewer spends time on logic that tools cannot judge, such as authorisation decisions.
Replace the placeholders: text in [square brackets] is for [Organisation] to set, such as the approved password hashing function or the secrets manager in use.

Review record

Field	Entry
Application and repository	[name, repository URL]
Change reference	[pull request or commit range]
Review type	[Diff-based / Baseline]
Risk tier of the application	[Tier 1 critical / Tier 2 business / Tier 3 low impact]
Target ASVS level	[L1 / L2 / L3]
Threat model consulted	[link, or "none exists"]
Automated results reviewed	[SAST run ID, secret scan run ID, dependency scan run ID]
Reviewer(s) and date	[names, date]

1. Authentication

[ ] Does every function that changes data or exposes sensitive data require an authenticated caller? (CWE-306, rank 21)
[ ] Are there no undocumented authentication pathways, such as a debug login, a legacy endpoint or a test bypass flag? (ASVS V6.3.4)
[ ] Are default accounts such as "admin" or "sa" absent or disabled? (ASVS V6.3.2)
[ ] Are passwords verified exactly as entered, without truncation or case changes, and are long passwords (at least 64 characters) accepted? (ASVS V6.2.8, V6.2.9)
[ ] Are passwords stored only with [Organisation's approved password hashing function] and the configured work factor? (ASVS V11.4.2) See the Password Hashing and Key Derivation Guide.
[ ] Is brute force and credential stuffing protection applied as the security documentation describes? (ASVS V6.3.1)
[ ] Do password reset and factor recovery flows avoid bypassing MFA? (ASVS V6.4.3)
[ ] Do failed logins return the same message, status code and timing whether or not the user exists? (ASVS V6.3.8)
[ ] If the application relies on an identity provider, are token signature, issuer, audience and expiry all validated? (ASVS V9.1.1, V9.2.1, V9.2.3) See the JWT Security Guide.

2. Sessions and tokens

[ ] Is every session token verified by a trusted back-end service, not by client-side code? (ASVS V7.2.1)
[ ] Is a new session token issued on login and re-authentication, and the old one terminated? (ASVS V7.2.4)
[ ] Does logout or expiry stop any further use of the session, including at the server for stateful tokens? (ASVS V7.4.1)
[ ] Are all of a user's sessions terminated when the account is disabled or deleted? (ASVS V7.4.2)
[ ] Is the signing algorithm taken from an allowlist, never from the token header? (ASVS V9.1.2)
[ ] Are session cookies set with Secure, HttpOnly and an appropriate SameSite value? See the Cookie Security Guide.
[ ] Are state-changing requests protected against cross-site request forgery? (CWE-352, rank 3) See the CSRF Prevention Guide.

3. Authorisation

[ ] Is every new endpoint or function restricted to callers with an explicit permission, with deny as the default? (ASVS V8.2.1; CWE-862, rank 4)
[ ] For every object identifier taken from the request (ID in a path, query or body), does the code check that this caller may access this specific object? (ASVS V8.2.2; CWE-639, rank 24)
[ ] Are field-level permissions enforced where some callers may read or write only part of a record? (ASVS V8.2.3)
[ ] Are authorisation checks made at a trusted service layer, never only in the user interface or client-side code? (ASVS V8.3.1)
[ ] When a service acts on behalf of a user, is access decided on the user's permissions, not the service's own? (ASVS V8.3.3)
[ ] Are only the fields the caller may set bound from the request, blocking mass assignment? (ASVS V15.3.3)
[ ] Are role or permission changes applied immediately, or is the delay documented and mitigated? (ASVS V8.3.2)
[ ] Do multi-step business flows enforce the expected step order? (ASVS V2.3.1)

Authorisation is the area tools judge worst and reviewers should spend most time on. See the Broken Access Control Prevention Guide.

4. Secrets and cryptography

[ ] Is the change free of hard-coded passwords, API keys, tokens, private keys and connection strings, including in tests, fixtures, comments and configuration files? (CWE-798)
[ ] Are back-end secrets read at runtime from [Organisation's secrets manager], not from source, container images or build arguments? (ASVS V13.3.1)
[ ] Does the identity that reads each secret have access only to the secrets it needs? (ASVS V13.3.2)
[ ] Are secrets configured to expire and rotate as the application documentation states? (ASVS V13.3.4)
[ ] Are secrets never written to logs, error messages, analytics or exception traces?
[ ] Do back-end connections use credentials other than defaults? (ASVS V13.2.3)
[ ] Are non-guessable values (tokens, reset codes, identifiers) generated with a cryptographically secure random generator? (ASVS V11.5.1)
[ ] Are only approved hash functions and algorithms used? (ASVS V11.4.1)
[ ] Do TLS clients in the change validate server certificates, with no verification switched off? (ASVS V12.3.2)

If a secret is found in the change, treat it as exposed even if the pull request is not merged: it is in the repository history and possibly in CI logs. Rotate it and follow the Leaked Credential Response Playbook. See also the Developer Secret Scanning Triage.

5. Input handling and output encoding

[ ] Is input validated against business expectations, preferably with an allowlist, at a trusted service layer? (ASVS V2.2.1, V2.2.2; CWE-20, rank 18)
[ ] Do database queries use parameterised queries or a safe ORM API, with no string concatenation of input? (ASVS V1.2.4; CWE-89, rank 2)
[ ] Are operating system calls avoided, or made with parameterised APIs and no shell interpretation of input? (ASVS V1.2.5; CWE-78, rank 9)
[ ] Is output encoded for its context (HTML, attribute, JavaScript, URL)? (ASVS V1.2.1, V1.2.2, V1.2.3; CWE-79, rank 1)
[ ] Is dynamic code execution (eval and similar) absent from paths that touch input? (CWE-94, rank 10)
[ ] Are file paths built from input canonicalised and confined to an allowed directory? (CWE-22, rank 6)
[ ] Are uploads checked for type, size and archive contents? (ASVS V5.2.1, V5.2.2, V5.2.3; CWE-434, rank 12) See the File Upload Security Guide.
[ ] Is untrusted data never deserialised into arbitrary object types, and are XML parsers set to refuse external entities? (ASVS V1.5.1, V1.5.2; CWE-502, rank 15)
[ ] Where the server fetches a URL influenced by input, is the destination checked against an allowlist and are redirects not followed unless intended? (ASVS V13.2.4, V15.3.2; CWE-918, rank 22) See the SSRF Prevention Guide.
[ ] Are resource-heavy operations limited so input cannot exhaust memory, CPU or storage? (CWE-770, rank 25)

6. Errors and logging

[ ] Do unexpected errors return a generic message with no stack trace, query or internal path? (ASVS V16.5.1)
[ ] Does the code fail closed, so an exception during an authorisation or payment step stops the action? (ASVS V16.5.3)
[ ] Are authentication attempts, successful and failed, logged? (ASVS V16.3.1)
[ ] Are failed authorisation attempts logged? (ASVS V16.3.2)
[ ] Are log entries free of secrets, session tokens and unnecessary personal data?
[ ] Are debug modes and verbose error pages off in production configuration? (ASVS V13.4.2)

See the Secure Error Handling and Logging Guide.

7. Non-human identities in the change

[ ] Does any new service account, API key, OAuth client or workload identity have a named owner and a documented purpose?
[ ] Are its permissions limited to what the change needs, with no wildcard scopes or administrator roles?
[ ] Is service-to-service authentication done with dynamically issued credentials rather than static shared keys? (ASVS V13.2.1)
[ ] If an AI agent or tool integration is added, does it use its own identity rather than a developer's token?

See the Service Account Security Guide.

8. Findings and sign-off

ID	Checklist item	Location (file:line)	CWE	Severity	Owner	Fix due	Status
[F-01]	[3.2]	[path:line]	[CWE-639]	[Critical / High / Medium / Low]	[name]	[date]	[Open / Fixed / Risk accepted]

Decision: [Approve / Approve with conditions / Reject].
Merge rule: [Critical and High findings block merge unless a risk acceptance is recorded under the exceptions process].
Sign-off: [reviewer name, date]; [second reviewer for Tier 1 applications].

Implementation guidance

Start with Tier 1 applications: require the full checklist for changes to authentication, authorisation, payment and data export code first, then extend.
Put the checklist where reviewers work: add sections 1 to 7 to the pull request template as collapsible sections, so items are ticked in the review rather than in a separate document.
Pilot for one month: run the checklist on two or three teams, record time taken and findings per review, and prune items that never apply to your stack.
Train reviewers on sections 3 and 4: authorisation and secrets findings need judgement; pair new reviewers with a security champion. See the Security Champions Programme Guide.
Review the template quarterly: add items for any vulnerability class that reached production, and update rank references when the CWE Top 25 is refreshed.

For AI-generated changes, apply this checklist and the additional checks in the AI-Generated Code Review Guide.

Metrics

Share of Tier 1 pull requests with a completed checklist.
Findings per review by section, to see where defects cluster.
Vulnerabilities found later (testing, bug bounty, production) in code that passed review, by checklist section.
Median time to close High findings.

Framework mapping

Framework	Reference	How the checklist supports it
NIST SP 800-218 (SSDF 1.1)	PW.7 Review and/or analyse human-readable code	Documented manual review with findings recorded
NIST SP 800-53 Rev 5	SA-11 Developer Testing and Evaluation; SA-15 Development Process, Standards, and Tools	Review criteria defined and applied consistently
NIST CSF 2.0	PR.PS-06	Secure development practice integrated and measured
OWASP ASVS 5.0	Encoding, validation, authentication, session, authorisation, token, cryptography, configuration and logging chapters	Each item cites the requirement it verifies

Common failure patterns

Ticking without reading: every box marked Yes on a large change reviewed in minutes. Track review time against change size.
Checking the UI, not the API: authorisation verified by clicking through the interface while the endpoint accepts any authenticated caller.
Secret removed, not rotated: a hard-coded key deleted in a follow-up commit but still valid and still in history.
Checklist drift: items that no longer match the frameworks or languages in use, so reviewers learn to skip them.

Standards and references

Related NHI Mgmt Group resources: Secure Code Review Guide · Secure Coding Guide · OWASP ASVS Guide · CWE Top 25 Guide

Secure Code Review Checklist: Authentication, Authorisation, Secrets and Input