Source-code security review — methodology

When it applies

You have (some of) the source. Whitebox review finds classes that blackbox misses — it follows data from where it enters to where it's dangerous, across the whole codebase at once.

Why it works

Vulnerabilities are source → sink flows with missing sanitization in between. Reading code lets you see the sink (dangerous function), trace back to a user-controlled source, and confirm nothing safe happens on the path — far faster and more complete than guessing from outside.

Method

1. Map the app: entry points (routes/controllers/handlers), auth/authz middleware, the ORM/ DB layer, config, and where user input enters. Note the framework — its defaults decide a lot.
2. Sink-first sweep: grep for dangerous functions per language (see code-review-dangerous-sinks) and for each hit, trace the argument back to a source. semgrep --config auto for a fast first pass.
3. Source-to-sink for each class: injection (query/exec/template), authz (missing owner checks → IDOR/BOLA), deserialization, SSRF (URL fetchers), file ops (path traversal/upload), crypto misuse, secrets in code.
4. Auth & access control: verify every sensitive route re-checks identity AND object ownership, not just "logged in". This is where the highest-impact bugs hide.
5. Track findings with file:line, the data path, and a PoC request; confirm dynamically where possible.

Gotchas

• A dangerous sink with a constant/allowlisted argument isn't a bug — confirm the source is user-controlled.
• Framework auto-escaping (ORM params, template autoescape) can neutralize an apparent sink — check config.
• Don't drown in semgrep noise; triage by exploitable source→sink, not raw hit count.

Verify success

For each finding: a concrete source→sink path with missing sanitization, ideally reproduced with a request/input that triggers it.

References

OWASP Code Review Guide; Semgrep rules; "Micro-methodology for code review" (GitHub Security Lab).