Open-redirect parameter scanner
An open redirect is a parameter on your site that sends visitors anywhere they ask — the building block of convincing phishing links, because the domain in the URL really is yours. Paste your own URL inventory to find the parameters that carry a destination, and which of them accept an off-site one.
Summary
How to use
- Paste URLs from a site you are responsible for — a crawl, a route list, your framework's URL map, or the query strings from your access logs.
- Add any project-specific parameter names your app uses for redirects. The built-in list covers about fifty conventional ones.
- Read the Level column. high means the value can point off-site as written. low means it holds a same-site path, which is the safe pattern. info is context.
- Untick strict to also catch parameters whose value looks like a redirect target even though the name gives nothing away —
?r=,?u=, and the custom names every codebase has. - Take the high-level findings and check each one against your server-side validation. This tool reads URLs; only your code knows whether the value is validated.
What it looks for, and why each pattern matters
An absolute URL in the value. If ?next=https://other.example works, the redirect is open. The domain a victim sees is yours; the page they land on is not.
A scheme-relative value — ?next=//evil.test. This is the one that defeats naive validation most often, because the check "does it start with /?" says yes, and the browser reads //host as an absolute URL to a different host. Backslash variants (/\evil.test, \\evil.test) exploit the same gap, since browsers normalise backslashes to slashes but string checks do not.
Encoded slashes — %2f%2f, %252f. A filter that inspects the raw value sees no slashes; the framework decodes before redirecting and there they are. Double encoding is the same trick one layer deeper.
Userinfo before the host — https://[email protected]. Everything before the @ is a username. A check for "does it contain our domain?" passes; the browser goes to evil.test.
Script-capable schemes — javascript:, data:. If a redirect parameter reaches location = value in client-side code, these execute in your origin, which is stored XSS rather than merely a redirect.
URLs in the fragment. The fragment never reaches your server, so server-side validation cannot see it — but a client-side router that reads location.hash and navigates will act on it. This is reported separately because it is invisible in server logs.
Fixing it properly
The only reliable fix is an allowlist of destinations, applied server-side. In order of preference: use a fixed set of named targets (?next=dashboard mapped to a path in code, so the URL never appears in the request at all); or accept only relative paths, validated by parsing the value and rejecting anything with a scheme, a host, or a leading // or \; or, if cross-domain redirects are genuinely required, match the parsed hostname against an explicit list of permitted hosts.
What does not work, and appears in real codebases constantly: checking that the value starts with your domain (defeated by yoursite.com.evil.test), checking that it contains your domain (defeated by the @ trick and by evil.test/?x=yoursite.com), blocklisting known-bad strings, or validating before decoding. Parse the URL with a real parser, then check the resulting host — never pattern-match the string.
Where a redirect to an arbitrary external site is a deliberate feature — an outbound-link tracker, for instance — the mitigation is an interstitial page that shows the destination and requires a click, plus rel="noreferrer", rather than a silent 302.
FAQ
Does this test my site?
No. It is static analysis of URL strings you paste — nothing is requested, and no payload is sent anywhere. It tells you where to look; confirming whether a parameter is exploitable means testing your own application, on a system you are authorised to test.
Why is a same-site path reported at all?
At low level, as inventory. A parameter holding /dashboard is behaving correctly, but it is still a redirect parameter — so it is where you check that the validation exists rather than assuming it does. Filtering to high-level findings gives you the ones that are already accepting off-site targets.
Can it find redirects that are not in a parameter?
No — path-based redirects (/out/https://…) and header-based ones are outside what a URL list can show. Those need a look at the routing code.
What about the values themselves — are they safe to paste?
Everything runs in your tab, so yes. If the URLs contain session tokens, run them through the URL privacy audit as well — a redirect parameter and a leaked token in the same URL is a worse problem than either alone.