scan.now
Premium Scan a site

Scan a Web Page for Reflected XSS Vulnerabilities

Enter a public page. Scan.now discovers its same-origin parameterized links and public GET forms, substitutes a unique inert marker into each input, and checks whether it becomes script markup in the returned HTML.

You can enter a normal page URL. Scan.now discovers public GET inputs on that page; if you already know the endpoint, you can paste its full parameterized URL. POST forms are never submitted.

A registered account is required to run this test. Finding status, evidence, affected locations and remediation are Premium-only. How active scanning works · Acceptable use

What a reflected XSS scan is looking for

Reflected cross-site scripting happens when a value from the request is copied into the returned HTML in a context where the browser treats it as markup or code. Search terms, filter values, error messages and redirect notices are common reflection points. Reflection alone is not enough: safely encoded text is expected and is not a vulnerability.

You can enter a normal page URL. Scan.now discovers same-origin links with query parameters and public GET forms on that page, then changes one discovered input at a time to a unique, inert script element and parses the returned HTML. A failure is recorded only when that exact marker becomes a script element in the response. The marker contains no executable JavaScript, the scanner does not submit forms, and it does not try to read cookies or user data.

Put this result in context

This scanner answers one part of the review. Continue with DOM XSS Scanner for find browser-controlled sources paired with dangerous sinks, then CSRF Scanner for inventory post forms and recognisable anti-csrf fields. These are separate checks because a strong result here does not prove that the adjacent surface is healthy.

For the background behind these signals, read Cross-Site Scripting (XSS) Explained: Reflected, Stored, DOM-Based and How to Prevent It and Website Security: What a Vulnerability Scan Looks For and How to Fix It. The Reflected cross-site scripting check reference explains the exact test, evidence and remediation used in the report. The Scan.now methodology explains request limits, scan boundaries and what the scanner deliberately does not attempt.

Reflected inputs and HTML evidence

The check is deliberately bounded to the signals below.

Coverage areaWhat the scanner examines
Automatic GET input discoverySame-origin parameterised links and public GET forms on the entered page supply bounded targets. You can also paste an exact endpoint when it is not linked from that page.
HTML parsing, not text searchA marker appearing as encoded text is safe for this check. It must be parsed as a script element before the result is confirmed.
Server-reflected outputThis check covers markup returned by the server. Client-side source-to-sink candidates belong to the separate DOM XSS scanner.

Confirmed, clear and untested outcomes

A scan result is evidence with a boundary, not a guarantee about every route.

Confirmed

The unique marker became a script element in the returned document. Treat the affected output context as a high-priority injection flaw.

No indicator

None of the tested parameters produced executable script markup. This is useful evidence for those exact URLs, not proof about every route or stored input.

No inputs discovered

The entered page exposed no suitable public GET form or parameterised link. Paste a known endpoint if it is not linked there, or scan the page where the input is visible.

Output encoding and safer rendering

Use the recommendations below to address confirmed findings and strengthen the surrounding control.

  1. Encode for the output context

    Use HTML, attribute, URL or JavaScript-string encoding appropriate to where the value is inserted; one encoder does not fit every context.

  2. Keep auto-escaping enabled

    Render untrusted values through the framework's normal escaped template syntax and review every raw-HTML escape hatch.

  3. Remove dangerous insertion APIs

    Prefer textContent and safe DOM construction over innerHTML, document.write or string-built event handlers.

  4. Add a restrictive CSP

    A nonce- or hash-based Content-Security-Policy reduces impact, but it is a backstop rather than a substitute for correct output handling.

  5. Turn the URL into a regression test

    Keep the vulnerable parameter and context in an automated test so the same template mistake cannot return unnoticed.

How it works

  1. Enter a relevant public page

    A normal page URL works. An exact parameterised endpoint is optional when the input is not linked or shown in a GET form on that page.

  2. We discover and isolate each input

    Public GET forms and same-origin parameterised links are collected, then a unique inert script marker replaces one value at a time.

  3. Review the private evidence

    Premium shows the affected parameter and path, plus remediation guidance; no executable payload is run.

What this tool checks

1 checks across 1 areas. Each links to its reference page with the test, the risk and the fix.

Full reference

Page content and JavaScript

1 check

The ones that most often decide the grade:

High Reflected cross-site scriptingA GET parameter was returned as executable script markup in the response.

Related tools

Continue the review with four checks that cover adjacent parts of the same attack surface.

All tools
Active Security DOM XSS Scanner

Find browser-controlled sources paired with dangerous sinks
Active Security CSRF Protection Scanner

Inventory POST forms and recognisable anti-CSRF fields
Websites Security Headers Checker

CSP, HSTS, frame and MIME policies
Websites JavaScript Library Vulnerability Scanner

Outdated libraries with known CVEs

Guides for this tool

Background reading written to go with these results.

8 min read · Updated Sep 19, 2026 Cross-Site Scripting (XSS) Explained: Reflected, Stored, DOM-Based and How to Prevent It

XSS lets an attacker run their own script in your users' browsers. The three types, what an attacker does with it and the layered...

Read the guide
13 min read · Updated Sep 13, 2026 Website Security: What a Vulnerability Scan Looks For and How to Fix It

A website vulnerability scan checks the parts of a site an attacker can reach without logging in: Transport security, HTTP headers,...

Read the guide
8 min read · Updated Sep 12, 2026 What Is a Vulnerability Scan? Types, Limits and What the Results Mean

A vulnerability scan checks a system against a list of known weaknesses and reports what matches. The types of scan, the difference...

Read the guide
8 min read · Updated Sep 14, 2026 Passive vs Active Scanning: What Each Can Find and When Each Is Appropriate

Passive scanning observes normal responses; active scanning sends crafted requests to trigger flaws. The boundary, why it matters...

Read the guide
9 min read · Updated Sep 18, 2026 How to Read a Security Scan Report: Severity, False Positives and What to Fix First

A scan report is a list of findings with severities, and the hard part is deciding what matters. How severities are assigned, how to...

Read the guide

Frequently asked questions

Does this scanner execute JavaScript in my visitors' browsers?

No. The probe is an inert script element with a unique data marker and no JavaScript body. Scan.now parses the response on its own server; it does not send the probe to another visitor.

Do I need to add a query string to the URL?

No. The scanner discovers public GET forms and same-origin parameterised links on the page you enter. Pasting the exact endpoint is optional and useful only when the input is not visible from that page. Use the DOM XSS scanner for a separate review of client-side sources and sinks.

Is seeing my search term on the page an XSS vulnerability?

No. Applications normally repeat search and filter values. It becomes dangerous only when the value reaches an executable HTML or script context without the encoding required for that context.

Can a Content-Security-Policy make the finding safe?

A strong CSP can block many injected scripts and is valuable defence in depth, but browser support, allowed script sources and policy mistakes leave gaps. Fix the unsafe output handling as the primary control.