loading
Mine a domain's archived URLs for redirect parameters, then confirm which ones send a browser to an attacker-controlled host.
Archived URLs are cleaned down to ones with redirect-style parameters.
Two testers inject a canary and check whether the site sends you off-domain.
An open redirect is a small bug that makes other attacks work. It lends your domain to a phishing link, it slips past an allowlist in an OAuth flow, and it turns a harmless-looking URL into one a user has no reason to distrust. Nobody tracks redirect parameters, because individually none of them look like a vulnerability.
This enumerates them from the application's own history and confirms which actually redirect off-site. You get the endpoint, the parameter, and the payload that moved the browser, which is enough to fix it without a reproduction call. It belongs in the same standing sweep as the rest of your offensive security checks, because redirect parameters get added by feature work, not by security work.
Pointing one detector at a URL list you already have is a smaller job than this. The candidate list here is built by the run: every archived URL recorded for the domain and its subdomains, deduplicated down to distinct parameter shapes, then filtered to the names that suggest redirection. Two detectors test that same list in parallel, so a case one of them handles poorly is still caught by the other. On a schedule, the confirmed list becomes a diff, which is where a parameter added last sprint shows up.
From a completed run against example.com.
gau recovered 9,412 archived URLs for the domain and its subdomains. 300 of them carry a redirect-shaped parameter and survive the filter. Candidates look ordinary, which is the point:
| url | param | payload | status | redirect |
|---|---|---|---|---|
| http://example.com/.well-known/webfinger?r=example.com | r | https://example.com | 404 | false |
| http://example.com/2001/cgi-bin/bbsN/index.cgi?command=viewres&target=9069373 | target | https://example.com | 404 | false |
| https://www.example.com/login?next=/dashboard | next | //example.com | 302 | false |
| https://dev.example.com/oauth/callback?redirect_uri=https://example.com | redirect_uri | https://target.example.com@example.com | 400 | false |
| https://example.com/go?url=https://example.com | url | /%09/example.com | 404 | false |
oralyzer requests every combination and reads where the response points:
[-] http://example.com/.well-known/webfinger?r=FUZZ/https://example.com [404]
[-] http://example.com/.well-known/webfinger?r=FUZZ///example.com [404]Nothing bounced off the origin on this run, which is the result you want. A finding names the parameter and the payload that left the origin. Redirects that stay on-domain are not reported, because they are the intended behaviour.
No. It substitutes a canary value into a parameter and reads where the response points. Nothing is chained onto a confirmed redirect, which is what makes it safe to run against production.
A crawl only reaches what the application links today. Archives hold parameters from older releases that are frequently still routed, and those are the ones nobody is checking.
The two disagree at the edges, on encoded payloads and protocol-relative targets among others. Running both against one candidate list costs a single extra pass and closes the gap between them.
No. On-domain redirects are the intended behaviour, so only destinations that leave the origin reach the report.
Redirect parameters arrive with feature work, not with security work. A recurring run against the same domain turns the confirmed list into a diff, so a newly added parameter is visible as new rather than buried in the same list as last month.
Get a personalized demo
A 30-minute walkthrough. We map the platform to your stack and answer pricing and deployment questions for your environment.