Prerequisites — this is the most demanding lesson in this category
White-box source code review builds directly on hands-on exploitation experience. Complete at least these lessons before arriving here:
- SQL Injection — sql-injection-data-extraction- Cross-Site Scripting —reflected-and-persistent-xssordom-xss
- Broken Access Control — broken-access-control- At least one of —command-injection-rce,path-traversal-file-access, orfile-inclusion-lfi-rfi
- Terminal familiarity — you will run grep/ripgrep commands against source code from the command line
If you have completed fewer than eight exploitation lessons, finish those first and return here.
Most of this curriculum has trained you as a black-box tester: you send requests, watch responses, and infer the bug from the outside. This lesson hands you the other vantage point — white-box source code review — where you have the code and can see the bug instead of guessing at it.
Authorised targets only. Reading source you are permitted to read (open-source projects, your own code, a client's code under contract) is low-risk. But the instant you turn a code finding into a working exploit against a running app, the usual rule applies: only the bundled Nebula application, your own copy, or an explicitly in-scope target. Review [Hacking Ethics and Authorization](/#/) first.
This is the complement to two things you already know. It is the read-the-code mirror of black-box testing, and it is the offensive twin of [Input Validation and Output Encoding](/#/) — that lesson taught you to write safe code; this one teaches you to read code, usually written by someone else, and find where it is unsafe.
Why bother reading the source when you can just fuzz? Because reading code finds what fuzzing structurally cannot:
- Logic and authorization gaps — a missing
if (user.isAdmin)is invisible to a fuzzer but glaring in the code. - Hidden and undocumented parameters — debug flags, backdoors, and endpoints no crawler discovers.
- Unreachable-by-default paths — code behind a feature flag or an unusual content type that black-box probing never triggers.
- The exact root cause — black-box tells you that a payload worked; the source tells you why, where, and precisely how to fix it.
White-box and black-box are partners, not rivals: you find a candidate in the code, then confirm it against the running app — and you confirm a black-box oddity by reading the handler behind it.
In this lesson you will:
- Adopt taint thinking — follow attacker-controlled data from a source (request params, headers, cookies, body) to a dangerous sink (a SQL string,
eval,child_process.exec,res.redirect,innerHTML). - Learn the dangerous-API inventory per language and the sink-first grep workflow.
- Grep the Nebula application source tree in the built-in code browser for a dangerous sink and trace it back to a user-controlled route.
- Write your own ripgrep/grep pattern to hunt JavaScript sinks.
- Take away how to turn a code finding into a tight source → flow → sink proof-of-concept.
Click Continue when you are ready.