Secure code review: check code before it ships

A secure code review reads your code the way an attacker would, looking for the flaws that scanners and ordinary review both miss. The OWASP Secure Code Review Cheat Sheet lays out a method any team can use. This guide turns it into a plan: which kind of review to run and when, what to look at, and how to review one pull request end to end.

Two kinds of review and when to run each. Simplified from the OWASP Secure Code Review Cheat Sheet.

What a secure code review adds

OWASP defines it as a person examining source code for security flaws that automated tools often miss. It does not replace scanners. Static and dynamic testing tools can point at suspicious areas, but the review relies on human judgment about how the app is meant to work.

It also differs from the code review your team already does. A functional review asks whether the code does what the ticket says. A security review asks how input is checked, how users are identified, what each user is allowed to do, how cryptography is used, and how someone could abuse the feature. The cheat sheet says manual review earns its keep on business logic, complex security code and flaws that only make sense in context.

Baseline and diff-based reviews

OWASP describes two kinds.

• Baseline review: the whole codebase. Use it for a new app or a major release, when you take on a legacy system, for a compliance cycle, and after a security incident.
• Diff-based review: only what changed. Use it on pull requests and commits, as features finish, and as part of everyday work.

The cheat sheet also names the moments where diff-based reviews fit into everyday work: the pull request itself, lightweight checks in pre-commit hooks, a review when a user story or feature is finished, a look at security in each sprint review, a quick review of every emergency hotfix, and reviews triggered automatically from continuous integration. Baseline reviews belong at the start of a project, before major releases, after architecture changes and after a breach.

Most teams need both. OWASP suggests a hybrid: baseline reviews for high-risk parts, diff-based reviews for routine changes, and a jump from a diff review to a baseline review when a change raises a serious concern.

Prepare before you read a line

For every review, OWASP says to understand the architecture and what the business needs, gather threat models and past findings, find the critical assets and high-risk functions, and read the security requirements.

A baseline review adds a map of the app's boundaries and dependencies, a look at the overall security design and incident history, and an audit of all third-party libraries. A diff-based review adds the list of changed files and components, the purpose of the change, its effect on existing security controls, and which changes carry the most risk.

Where to look: high-risk code patterns

The cheat sheet lists the code that deserves the closest reading:

• Input processing and validation
• How database queries are built, including ORM use
• File operations and path handling
• Sign-in and session logic
• Authorization and access control checks
• Cryptography and key management
• Error handling and logging
• Configuration loading and environment variables

OWASP also gives quick searches that find candidates in seconds: hardcoded values named password, api_key or secret; risky calls such as eval(, exec(, innerHTML and document.write; and queries built by adding strings. Each hit is a place to read, not a finding by itself. Our guides to SQL injection testing and XSS testing show how to confirm them.

Follow the data and think like an attacker

Data flow. Start at the sources: user input, uploads, API calls, database reads, environment variables. Follow each one through validation and business logic to its sinks: queries, file writes, rendered pages, logs and outside APIs. At every trust boundary, check that input is validated and output is encoded, and that sensitive data gets the protection its class needs.

Threats. Line the review up with known attack patterns: the OWASP Top 10, STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), attack trees and abuse cases.

Business logic. Check that state moves only in allowed steps, that races cannot double an action, that transactions roll back cleanly, that quotas hold, and that every step of a workflow checks authorization. Our posts on transaction authorization and broken access control cover two of the commonest logic flaws.

Worked example: review one pull request

Say a pull request adds "export my invoices as CSV". Here is a diff-based review following OWASP's steps.

1. Purpose and files. Read the description. List the changed files: a new route, a query, a file writer.
2. Sources and sinks. The source is a date range from the user. The sinks are a database query and a file sent back to the browser.
3. Patterns. Is the query built with parameters, not string joins? Is the file name built from user input?
4. Authorization. Does the route check that the invoices belong to the signed-in user, not just that someone is signed in?
5. New attack vectors. Can a huge date range exhaust the server? Does an error expose a stack trace?
6. Regression. Does the change touch a shared helper, such as the session check, that other routes rely on?
7. Record. Write each finding with the file, the risk and the fix, using a standard template, and add any new pattern to your team's list of common issues.

OWASP's team advice fits here: use standard checklists, keep a knowledge base, track how well reviews catch issues, and fit reviews into the flow you already have, such as pull requests and CI/CD.

A second opinion before you commit

whitehatstoic offers independent reviews: "A second opinion before you commit", with a plain written verdict on a project, codebase or vendor, covering codebase review, vendor review and a clear recommendation. For testing the running app, its cybersecurity and AI safety testing includes a written report with fixes and a retest after you apply them. Both are custom quotes, scoped after a short call. No review finds every weakness, but an outside reader sees what the authors stopped noticing.

Frequently asked questions

Does a scanner replace a secure code review?

No. OWASP says manual review complements automated tools. Tools point at suspicious areas; a person judges business logic and context that tools miss.

How often should we run a full review?

OWASP suggests a baseline review at project start, before major releases, after architecture changes and after security incidents, with diff-based reviews on everyday changes.

Who should do the review?

OWASP names three roles: security reviewers who analyse, developers who fix, and security champions who connect the two.

Get started

Run OWASP's three quick searches on your codebase today, then add a security question list to your pull request template.

Building something that has to be safe? Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan and a price.