OWASP secure code review guidance exists because reading unfamiliar code for security defects, without a structure, tends to drift toward whatever catches the reviewer's eye rather than systematically covering the areas most likely to hide real vulnerabilities. This checklist follows the general categories OWASP's code review guidance emphasizes, adapted into a practical review sequence.
Where Should a Secure Code Review Actually Start?
Start with authentication and session management, since flaws here tend to have outsized impact. Check how credentials are validated, whether password comparisons use constant-time functions rather than simple equality checks, how session tokens are generated (cryptographically random, not predictable), and whether session tokens are properly invalidated on logout and after privilege changes.
Move next to access control. Look specifically for missing authorization checks on individual endpoints — a common pattern is an application checking authentication ("is this user logged in") without a corresponding authorization check ("is this specific user allowed to access this specific resource"), which produces broken object-level access control, one of the most commonly exploited API vulnerability classes in practice.
What Should You Look for in Input Handling?
Trace every point where external input enters the application — request parameters, headers, file uploads, third-party API responses — and verify it's validated or sanitized before use in a sensitive context. That means checking for SQL and NoSQL injection risk anywhere input reaches a database query, checking for command injection anywhere input reaches a shell call or subprocess invocation, and checking for path traversal anywhere input constructs a file path.
Pay particular attention to deserialization. Unsafe deserialization of untrusted data (particularly in languages like Java, PHP, and Python where deserialization can trigger arbitrary code execution) is a recurring, high-severity finding in code review for security across many codebases, and it's easy to miss because the vulnerable call often looks like ordinary object-loading code.
How Should Output and Data Exposure Be Reviewed?
Check that output rendered in a browser context is properly encoded for its destination context (HTML, JavaScript, URL, or CSS), since context-appropriate encoding is what actually prevents cross-site scripting — encoding for the wrong context is a common near-miss that still leaves an XSS path open. Separately, check for sensitive data exposure: are secrets, tokens, or credentials ever logged, included in error messages, or returned in API responses that don't need them?
What Should a Reviewer Check Around Cryptography and Configuration?
Look for hardcoded secrets and credentials committed directly in source, use of deprecated or weak cryptographic algorithms (MD5 or SHA-1 for anything security-sensitive, for example), and improperly configured TLS settings. Also review error handling — verbose stack traces or debug information returned to end users in production is a low-effort finding that shows up constantly and gives attackers a free look at internal implementation details.
How Does Manual Review Relate to Automated SAST Scanning?
Automated static analysis tools catch a meaningful share of these patterns reliably and at far greater speed than manual review, particularly for well-known vulnerability classes with recognizable code signatures. But manual review remains essential for business-logic flaws — an authorization bypass that requires understanding what a specific endpoint is supposed to do, not just what pattern its code matches, is exactly the kind of finding automated tools consistently miss.
The practical approach most mature AppSec programs land on is layering both: automated SAST scanning on every commit to catch known patterns immediately, with focused manual secure code reviews reserved for high-risk components (authentication, payment handling, access control logic) where business-logic understanding actually changes the outcome. Our SAST/DAST product page covers how automated scanning fits into that layered approach, and our Academy has deeper walkthroughs of specific vulnerability classes for teams building out this checklist internally.
FAQ
How long should a secure code review take?
It depends heavily on scope — a focused review of a single authentication module might take a few hours, while a full-application review for a compliance requirement can take days or weeks. Time-box reviews around risk, not around covering every line equally.
Does OWASP publish an official secure code review checklist?
OWASP's Code Review Guide and related project documentation outline the categories and methodology this checklist follows, though OWASP presents it as a framework and methodology rather than a single rigid checklist to execute verbatim.
Can secure code review replace penetration testing?
No — they catch different things. Code review finds issues visible in source that may never surface in behavior testing, while penetration testing finds exploitable behavior that may originate from configuration or infrastructure issues invisible in the application source alone.
Who should perform secure code reviews?
Ideally a mix — a developer familiar with the codebase paired with someone with dedicated security review experience, since the first understands intended behavior and the second recognizes exploitation patterns the first might not think to look for.