Code Review for Security

CAP, ACID vs BASE, latency numbers, back-of-envelope estimation, single points of failure — the vocabulary every system designer thinks in.

Core Philosophy: A penetration tester (Phases 2–3) attacks software from the outside, seeing only its behavior. A security code reviewer reads the source itself — and sees what the outside attacker cannot: the actual logic, the missing check, the unsafe construction, the dangerous pattern. This is white-box security work, and it is where a developer’s deepest skill — reading and understanding code — becomes a security superpower. You already read code. This page is reading it for vulnerabilities.

Part 1: The Problem

In Phases 2–3 you tested software as a black box — from the outside, seeing only inputs and outputs, inferring the flaws inside. That is a real and valuable skill. But it has limits: from outside, you can only find what you can trigger and observe, you cannot see why a flaw exists, and subtle issues may never surface through behavior alone.

Security code review is the complementary approach: examining the source code itself to find vulnerabilities. This is white-box work — full visibility into the actual implementation. It can find what black-box testing misses, find the root cause directly, and catch flaws before the software is ever deployed (the “shift left” of 5B.1).

And for a developer switching into security, code review is the most natural skill of all — because reading and understanding code is the thing you have done for years. This page reorients that existing skill toward security.

Part 2: The Concept — Black Box vs White Box

The distinction frames everything in this page:

   BLACK BOX (Phases 2–3)         WHITE BOX (this page)
   test from outside              read the source itself
   see behavior only              see the actual logic
   infer flaws from symptoms      see flaws directly
   finds what you can trigger     finds what you can read
   the attacker's usual view      the reviewer's privileged view

Neither replaces the other — they are complementary, and a mature AppSec practice uses both. But white-box security code review has specific strengths:

• It sees the root cause. Black-box testing shows a symptom (“this input causes an error”); the code shows the cause (“this query is built by string concatenation”). Recall from Phase 4 that real fixes address root causes — code review finds them directly.
• It finds what behavior hides. A missing access-control check (2.7), a subtle logic flaw (5A.2’s business logic), an unsafe pattern that has not yet been triggered — visible in code, often invisible from outside.
• It is preventive. Code review happens before deployment — catching vulnerabilities while they are cheap to fix (5B.1’s shift left).
• It is systematic. You can review all the code, methodically — not just the parts an external tester happened to reach.

The reviewer has the privileged position the external attacker wishes they had: they can simply read what the software does.

Part 3: The Concept — What to Look For

A security code review is not “read all the code and hope to notice something.” It is targeted — you know the vulnerability classes (Phases 2–4), so you read code looking for where they would live. Your Phase 2/4 knowledge tells you exactly what to hunt for.

The reviewer’s mental checklist — read the code looking for each:

Injection points (2.4, 4.1). Anywhere the code builds a command, query, or instruction for an interpreter. Look for the dangerous pattern: a command/query built by string concatenation with input rather than parameterized. This is one of the most reliably findable vulnerabilities in a code review — the unsafe construction is visible.

Output handling / XSS (2.5, 4.1). Anywhere user-controlled data is placed into a web page. Is it properly, context-appropriately encoded? Or written raw? Look especially for uses of the framework’s “raw HTML” escape hatch.

Authentication and session logic (2.6, 4.2). How are passwords stored (salted, slow hash — or wrongly)? How are sessions managed? Is a fresh session issued at login? Is logout server-side? Are tokens properly signed and verified?

Access control (2.7, 4.2). The most important and most rewarding thing to look for in code review. For every sensitive operation and data access, is there a server-side check that this user is authorized for this specific thing? Broken access control is a bug of omission (2.7) — and code review is uniquely good at finding omissions, because you can see the check that should be there and is not.

Request forgery (2.8, 4.2). Anti-CSRF protection present? Server-fetch features (SSRF) properly restricted?

Secrets in code (2.10, 4.2). Hard-coded passwords, API keys, tokens, credentials — directly visible in a code review, and a very common real finding. Search the code for them.

Vulnerable dependencies (2.10). What does the code import? Are those components current and free of known vulnerabilities?

Input validation (4.1). Is untrusted input validated (server-side, allowlist) as a defense-in-depth layer?

Error handling (2.9). Do errors leak sensitive internal detail? Does the code fail securely / fail closed (4.3)?

Business logic (5A.2). Does the code’s logic correctly enforce the application’s intended rules, or can the workflow be abused?

Notice: this entire checklist is Phases 2 and 4. Security code review is applying everything you already know — but reading it in the source rather than triggering it from outside.

Part 4: The Concept — How to Conduct a Review

A security code review, like a pentest (2.11), benefits from methodology — a structured approach so nothing is missed.

A practical approach to reviewing code for security:

   1. UNDERSTAND the application — what it does, its
      architecture, its trust boundaries (1.2). You cannot
      review code well without understanding the system.

   2. IDENTIFY the high-risk areas — where the security-
      sensitive code is: authentication, access control,
      input handling, anything touching sensitive data,
      anything crossing a trust boundary. Prioritize these.

   3. TRACE the data flows — follow untrusted input from
      where it ENTERS the application to where it is USED.
      Most vulnerabilities are "untrusted input reaching a
      dangerous operation without proper handling in between."

   4. REVIEW against the checklist — for the high-risk code,
      methodically check each vulnerability class (Part 3).

   5. VERIFY findings — confirm a suspected flaw is real;
      understand its impact.

   6. DOCUMENT — clearly, with the location, the issue, the
      impact, and the fix (the reporting discipline of 2.11).

The single most important technique here is data flow tracing (step 3). Most vulnerabilities have the same shape: untrusted input enters somewhere, travels through the code, and reaches a dangerous operation (a query, a command, a page, a sensitive action) without being made safe along the way. The reviewer’s core skill is following that journey — “where does untrusted data come in, where does it end up, and is it handled safely in between?” This is the source-code version of the trust-boundary thinking from threat modeling (1.2).

A few practical points:

• Prioritize by risk. You cannot deeply review every line of a large codebase. Focus on the security-sensitive, high-risk areas first (the risk-prioritization principle from 1.1 and 4.8).
• Understand before judging. A pattern that looks wrong may be safe in context; one that looks fine may be unsafe. Understand what the code actually does.
• Use the developer’s-eye advantage. You read code fluently — use it. You can follow logic, understand structure, and spot “this is not how this should be done” because you have written code yourself.

Part 5: The Concept — Manual Review and Automated Tools

Security code review has two modes — automated and manual — and a competent reviewer uses both, understanding what each is for. (The automated tools are detailed in 5B.3; here is how they relate to review.)

Automated code analysis (SAST — covered fully in 5B.3). Tools that automatically scan source code for security issues. Their strengths: speed, breadth (they can scan an entire large codebase), consistency, and the ability to run continuously. Their limits: they produce false positives (flagging non-issues) and false negatives (missing real issues — especially anything requiring understanding of what the application is for, like business logic flaws and many access-control issues). A tool does not understand context or intent.

Manual review. A skilled human reading the code. Strengths: understands context, intent, and application logic; can find business logic flaws, complex access-control issues, and subtle problems tools miss; can judge real impact. Limits: slow, cannot cover huge codebases exhaustively, depends on reviewer skill.

   AUTOMATED (SAST)              MANUAL REVIEW
   fast, broad, consistent       deep, context-aware
   runs continuously             understands intent & logic
   finds known unsafe patterns   finds logic & access-control flaws
   false positives & negatives   slow, can't scale to huge code
   ──────── used TOGETHER, they complement each other ────────

The competent approach: automated tools for breadth and continuous coverage; manual review for depth on the high-risk areas. Tools triage and cover the codebase; the human reviews where understanding is needed. A reviewer who relies only on tools misses the logic and access-control flaws that matter most; one who tries to manually review everything cannot scale. Use both, each for what it is good at — the same “automated + manual” complementarity you saw with scanning vs pentesting in 4.8.

A note on AI-assisted code review: AI tools are increasingly used to help review code for security. They are genuinely useful — but, exactly like SAST, they produce confident output that must be verified, and they miss context. Phase 6.7 covers AI as a security tool directly; for now, treat AI code-review output the way you treat any tool output — a useful input that a skilled human verifies, never a substitute for understanding.

Part 6: The Concept — Code Review as a Practice, Not Just a Skill

The final framing: in a real AppSec role, security code review is not only a skill you have — it is a practice you help establish across the development organization (the 5B.1 principle that AppSec makes secure development everyone’s property).

What this means:

• Security in regular code review. Developers already review each other’s code (peer review) as normal practice. A major AppSec contribution is helping security become part of that existing review — so security is checked continuously, by developers, on every change, not only in a separate AppSec pass.
• Reviewing the high-risk changes. The AppSec engineer focuses their own manual review on the highest-risk code and the highest-risk changes — where expert security review adds the most.
• Enabling developers to review for security. Providing developers with the knowledge, checklists, and guidance to spot security issues in their own and each other’s code. This scales security review far beyond what the AppSec engineer could do alone.
• It feeds the whole SDLC. Code review findings feed back: into developer guidance, into secure coding standards, into what the automated tools (5B.3) should catch, into training. Patterns found repeatedly become things to prevent systematically.
• It connects to working with developers (5B.5). How code review findings are communicated to developers — as helpful collaboration, not as criticism from a gatekeeper — determines whether they get fixed and whether developers stay engaged. 5B.5 covers this directly.

🔑 The deep lesson: security code review is white-box security work — reading the source to find vulnerabilities directly, at their root cause, before deployment. It applies everything you learned in Phases 2 and 4, but as reading rather than attacking — and it is the most natural security skill for a developer, because you already read code fluently. The core technique is tracing untrusted data from entry to dangerous use. Automated tools and manual review complement each other. And in a real role, code review is something you help make a practice across the whole development organization — not a thing only you do.

📓 Key Terms

🧪 Hands-On Lab

Review code in deliberately vulnerable applications (which often ship source), open-source projects, and your own code. The deliberately vulnerable apps from Phase 2 are ideal — you can review the source and you already know the bugs.

Task 1 — Review vulnerable source. Take a deliberately vulnerable app whose source you have. Review its code for the vulnerability classes in Part 3. Find the bugs in the source — and connect each to the bug you exploited from outside in Phase 2. See the same vulnerability from both the black-box and white-box sides.

Task 2 — Trace a data flow. Pick one input in an application’s code. Trace it: where does it enter? where does it travel? where does it end up? Is it handled safely along the way? Practice the core reviewer technique on a real flow.

Task 3 — Hunt for hard-coded secrets. Take a few real codebases (open-source, or your own old projects). Search them for hard-coded secrets — credentials, keys, tokens. This is a quick, common, real code-review finding.

Task 4 — Review for access control. In a deliberately vulnerable app’s source, find every sensitive operation and check: is there a server-side authorization check verifying this user may do this thing? Practice finding the missing check — the omission that is broken access control.

Task 5 — Run a SAST tool. Use a free/open-source static analysis (SAST) tool on a codebase. Read its output. Identify false positives (flagged non-issues) and consider what it likely missed. Understand the tool’s strengths and limits firsthand.

Task 6 — Compare manual and automated. For one codebase, compare what you found by manual review against what the SAST tool found. What did each catch that the other missed? Confirm Part 5’s lesson for yourself.

Task 7 — Conduct a full structured review. Take one application’s source and conduct a complete security code review using the Part 4 methodology — understand it, identify high-risk areas, trace data flows, review against the checklist, document findings with location, impact, and fix.

Task 8 — Build a code-review note. In Notion, create a “Security Code Review” page with the black/white-box distinction, the what-to-look-for checklist (Part 3), the review methodology (Part 4), and the manual-vs-automated framing. Your reviewer’s reference.

⚠️ Common Mistakes

• Reading code with no methodology. “Read it all and hope to notice something” misses things. Use a structured approach — understand, prioritize high-risk areas, trace data flows, check against the vulnerability-class checklist.
• Not tracing data flows. Most vulnerabilities are untrusted input reaching a dangerous operation unsafely. Following that journey is the core reviewer skill.
• Reviewing everything equally. Large codebases cannot be deeply reviewed line by line. Prioritize the security-sensitive, high-risk areas (risk-based, 1.1/4.8).
• Relying only on automated tools. SAST has false positives and false negatives — it misses logic and access-control flaws especially. Tools and manual review complement each other.
• Trusting tool (or AI) output without verifying. Automated and AI output is a useful input, not a verdict. A skilled human verifies — context is what tools lack.
• Missing omissions. Broken access control is a missing check. Code review is uniquely good at finding what is not there — but only if you actively look for the absent check.
• Communicating findings as criticism. How findings reach developers decides whether they get fixed. That is 5B.5 — collaboration, not gatekeeping.

✅ Recap & What’s Next

• Security code review is white-box work — reading source to find vulnerabilities directly, at their root cause, before deployment — and the most natural security skill for a developer.
• It targets the vulnerability classes from Phases 2 and 4; the core technique is tracing untrusted data from entry to dangerous use; broken access control (a missing check) is especially findable in code.
• Automated tools (SAST) and manual review complement each other — breadth and continuity vs depth and context; and in a real role, code review is a practice established across the whole development organization.

Next (5B.3): Code review and the other SDLC security activities are far more powerful when automated and woven into the development pipeline. Page 5B.3 is security testing automation — SAST, DAST, dependency scanning, and CI/CD security gates.