A scanner finds reflected XSS in three phases: it lists every input the page accepts, sends harmless marked test values, then reads the response to see which special characters came back unencoded. If markup characters survive in an executable position, it reports a finding.
Phase 1: detect input vectors
The OWASP testing guide describes a black-box test as at least three phases, and the first is detecting input vectors. For each page the tester determines every user-defined variable and how to supply it. That includes hidden or non-obvious inputs such as HTTP parameters, POST data, hidden form fields and predefined radio or select values. A crawler collects these from links, forms and, in better tools, from JavaScript.
If the crawler never finds a parameter, it never tests it. Coverage here is the biggest limit on any reflected XSS scan.
Phase 2: analyze each input
For each input, the scanner sends specially crafted data. The guide says this data is typically harmless but triggers a response that shows the vulnerability, and that it can come from a fuzzer, a predefined list of attack strings or manual work. Its examples are simple script tags, and it points to a longer filter evasion list for others.
A good scanner usually sends two kinds of value:
- A unique marker with special characters, such as a short random token followed by a quote and angle brackets, to see what comes back.
- A context-specific probe, once it knows where the marker lands.
Phase 3: check the impact
Next the tool reads the response and searches for the test input. The testing guide says the tester then identifies which special characters were not properly encoded, replaced or filtered. Ideally the HTML specials are turned into entities: the greater than and less than signs, the ampersand, the single quote and the double quote. Inside JavaScript or an attribute, a different set matters, including newlines, backslashes and unicode escapes.
This is why context matters. The same input can be safe in the body of a page and dangerous inside a quoted attribute or a script block. The guide also notes that proper character encoding is one of the main difficulties: an app may block a plain script tag but miss the same text in a different encoding.
| What the scanner sees | Likely meaning |
|---|---|
| Marker returned with specials turned into entities | Handled for that context |
| Marker returned with raw quote inside an attribute | Probable XSS, confirm |
| Marker returned raw inside a script block | Probable XSS, confirm |
| Marker not returned | Not reflected here, or reflected elsewhere |
Where scanners get fooled
- False positives. The marker appears raw but in a spot the browser does not run, such as inside a comment or a text area. Good tools confirm in a real browser engine.
- False negatives from filters. A web filter may block the scanner's probe string but not a variant.
- Single page apps. The reflection may happen in the browser through JavaScript. See reflected, stored and DOM XSS.
- Content types. A response served as JSON or plain text does not execute script the same way as HTML.
- State and tokens. Parameters that need a valid token or earlier step may never get a proper test.
Making your own scans better
- Scan while logged in so authenticated pages are included.
- Import your API definition so parameters that never appear in links are tested.
- Check the list of tested URLs and parameters, not only the findings.
- Confirm each reported hit in a browser before filing it.
- After the fix, replay the request. See how to retest an injection finding.
Try it yourself
Click through it at your own pace, or open it full screen. Watch which pages and inputs the crawl discovers before any test begins.
Quick check
Why does my scanner say XSS but the alert never pops?
The marker may be reflected in a place the browser does not execute, or the tool may have flagged it from the response text alone. Confirm in a real browser and look at the exact context.
What fixes reflected XSS?
OWASP recommends context-sensitive output encoding on the server, with input validation as support.
Safeguard has a free scan at gold.safeguard.sh/scan for the front-end libraries in your project.
Sources
Last reviewed: 19 October 2026.
