Injection
Six scanners, one mechanism. Each finds a place where outside data enters the app, puts a marker there that it can recognise later, and reads one specific signal back: a database error, a callback, a canary with its angle brackets intact, a hooked browser sink, an accepted upload, or a source-to-sink path in the code. A finding is reported only when the signal is specific to the marker.
How this group works
Every injection scanner is a marker and an oracle. The marker is what the scanner puts into the app; the oracle is the one signal it reads back. The lanes below are the six scanners in this group, one per row, and the columns switch on in the order the scanner moves through them.
1Six scanners, one shape. Each starts from a place where outside data enters: a query, body or path parameter, a form field, a filename, a URL the server will fetch, or, for the static analyzer, a request object in the code.
2Each sends a marker it can recognise later: a quote that breaks SQL, the cloud metadata address, a canary wrapped in angle brackets, a traversal filename. Taint analysis sends nothing; it marks the variable that holds request data and follows it.
3The target processes the marker. Everything goes through one rate-limited client, read-only payloads only, and every scanner checks its time budget per endpoint so it returns what it has instead of being cancelled.
4Each scanner reads one specific signal: a database error string or a delay, metadata text or an out-of-band callback, the canary with its brackets intact, a hooked browser sink, a 2xx with evidence the file was stored, a sink call in code.
5The rule: report only when the signal is specific to the marker. Canary text alone is not enough, the brackets must survive; a one-off delay is not enough, it must reproduce; a sink name in a bundle is not enough, the canary must arrive in a real browser. File upload needs more than a 2xx: the body must not be a failure and the stored file or name must be visible.
6Every finding lands in one category, Injection Risk. That is what lets the correlator pair a dynamic hit with a static taint path on the same route and raise both to a confirmed finding.
Scanners in this group
Active injection
Six oracles for SQLi, command, NoSQL, XXE and SSTI, the re-measure rule for time-based blind SQLi, and the LLM adjudicator that drops heuristic false positives.
Server-side request forgery
Your server as the attacker's proxy to cloud metadata, URL sinks hiding in form fields, and out-of-band callbacks that prove a blind fetch.
Taint analysis
Source to sink, with and without a sanitizer. Why fifty lines of stack-tuned Semgrep rules beat the stock packs, and where the LLM still earns its keep.
Cross-site scripting
A canary with angle brackets, the text/html gate, seven injection contexts with their breakout payloads, POST bodies with the form's real field names, and the stored read-back.
DOM XSS in a real browser
Twelve sinks hooked before the app's JavaScript runs, four injection vectors in order, and an interactive oracle that types into search boxes and watches the DOM.
File upload
Upload endpoints found by path, an HTML and an SVG file posted as multipart, three traversal filenames, and the rule that decides: a 2xx with a non-failure body and evidence the file was stored.
At a glance
| Scanner | What it looks at | What it reports | Severity | Needs |
|---|---|---|---|---|
Active injectionactive_injection_scanner | Query, body and path parameters on every endpoint, up to 5 params each | Error-based and time-based SQLi, command injection, NoSQL, XXE, SSTI | Critical | Target URL. Time-based SQLi only at --depth deep. LLM key for the adjudication pass. |
SSRFssrf_scanner | URL-shaped parameters, including ones hiding in form fields | Internal IP and cloud-metadata fetches; blind SSRF via out-of-band callbacks | High–Critical | Target URL. OOB callback server for the blind cases. |
Semgrep taintsemgrep_taint | Cloned repo: JS/TS, Python, Java, Kotlin rule packs | Source-to-sink paths without a sanitizer: SQLi, XSS, SSRF, path traversal, command injection, SSTI | High–Critical | Repository. The [taint] extra and the semgrep binary; no-ops without it. |
XSSxss_scanner | GET query params (URL, discovered, then a capped fallback list) and POST/PUT/PATCH bodies using the form's discovered field names | Confirmed reflected XSS (GET and POST body), context-aware breakouts, stored XSS on read-back, possible XSS when encoded, static DOM sinks | Low–Critical | Target URL. Auth headers when a session exists. Static DOM sink pass only at --depth deep. |
DOM XSSdom_xss_scanner | Page URLs in a headless Chromium: query params, hash, postMessage, typed inputs | Confirmed DOM XSS with the exact sink and source | High | Target URL and Playwright. Runs on crawled pages with the session when credentials exist, otherwise on page-like URLs from discovery. |
File uploadfile_upload_scanner | Endpoints whose path contains an upload indicator (/upload, /file, /media, /attachment, /image, /avatar, /document, /import) | Dangerous file types accepted (.html, .svg); path traversal filename accepted | High (type) · Critical (traversal) | Target URL. Auth headers when a session exists. |
Why this class matters
Injection is the attacker's input being interpreted as code or as a command by something on your side: the database, the shell, the XML parser, the template engine, the browser, the filesystem. The impact is whatever that interpreter can do. SQL injection reads or rewrites the whole table. XSS runs JavaScript as your users, which means their tokens, their actions and any form on the page. SSRF turns the server into a proxy to the cloud metadata service that hands out IAM credentials. An accepted .svg upload is stored XSS on your own domain, and an accepted traversal filename is a write anywhere on the filesystem.
Real-world breaches
SQL injection led to the theft of 130 million credit and debit card numbers, one of the largest breaches in history at the time.
An SSRF vulnerability in a WAF configuration reached the AWS metadata endpoint (IMDSv1), yielded IAM credentials, and exposed 100+ million customer records from S3. Capital One was fined $80 million.
The Magecart group injected malicious JavaScript into the payment page and skimmed 380,000 customers' card details. The ICO fined BA $26 million. There was no Content Security Policy and user input was rendered without sanitization.
CVE-2016-3714 in ImageMagick allowed remote code execution via crafted image files. Any service that accepted user-uploaded images and processed them with ImageMagick was vulnerable.