Source-Code Analysis
What this domain tests
Source-Code Analysis tests white-box review and SAST interpretation: can you find a taint path, judge whether a sanitizer is effective, and distinguish a real vulnerability from a pattern match?
Core rules
- Taint analysis tracks sources such as request parameters, headers, files, and queues to sinks such as SQL execution, OS commands, template rendering, deserialization, and redirects.
- A sanitizer only counts if it is on every path, applied to the correct data, and appropriate for the sink context. Decoding after validation often breaks the guarantee.
- Review authorization in each code path, not only at the controller. Mass assignment and missing tenant filters are common.
- Secrets belong outside source and history; dependency and build-pipeline risks are part of the code review.
- Prefer dataflow evidence and a reproducible request over a grep hit.
Worked example
A Spring controller takes @RequestParam name and builds entityManager.createQuery("FROM User WHERE name = '" + name + "'"). The source is the request parameter, the sink is query creation, and there is no effective sanitizer. A request containing a quote changes the query structure. The fix is a named parameter: ... WHERE name = :name with setParameter. The reasoning is that concatenation makes input part of the query grammar; parameter binding keeps it as data. Add a test that sends a quote and asserts no error and no extra rows.
Traps
- Assuming a WAF or validation annotation sanitizes every path.
- Missing second-order flows where stored data reaches a sink later.
- Treating generated or vendored code as automatically safe.
- Reporting a dependency CVE without checking whether the vulnerable function is reachable.