Open Redirect Check
Enter a URL — ideally a page that takes a redirect parameter, like a login, logout, SSO or click-tracking endpoint — to test it for an open redirect. An open redirect is a parameter whose value the server uses, unvalidated, as the destination of a redirect, so a link on YOUR own domain can silently bounce a visitor to an attacker's site. That makes phishing links far more convincing and is a classic stepping stone to OAuth/SSO access-token theft. The scanner tries the common redirect parameter names with a foreign sentinel destination and reports a finding only when the endpoint actually redirects there.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- Common redirect parameters: next, url, redirect, redirect_uri, redirect_url, return, return_url, returnTo, dest, destination, continue, goto, target, r, u
- Absolute (https://attacker) and protocol-relative (//attacker) payload forms, plus backslash variants some URL parsers normalise
- The raw Location header on a 3xx response — redirects are not followed, so the destination is read exactly as the server set it
- Client-side redirects too: a <meta http-equiv=refresh> tag or a JavaScript location assignment pointing off-domain
How to read the result
- OK = no parameter sent visitors to the external sentinel host; the endpoint either ignores the parameter or keeps redirects within its own domain.
- Warn = an open redirect is confirmed: the named parameter redirected to an arbitrary external host. The finding shows the exact parameter, payload, mechanism (Location / meta-refresh / JS) and HTTP status.
- A parameter is flagged only when the destination host equals the test sentinel exactly — never on a substring — so a legitimate in-domain redirect does not false-positive.
- Each finding is reproducible with a single curl using the shown parameter and payload.
Frequently asked questions
Why is an open redirect a security problem?
Because the malicious link lives on your trusted domain. A victim sees yourdomain.com in the link, trusts it, clicks, and is silently forwarded to an attacker's page — ideal for phishing. Open redirects are also frequently chained with OAuth/SSO flows to exfiltrate authorization codes or access tokens by redirecting the token to an attacker-controlled URL.
Is the test safe and non-destructive?
Yes. Every probe is a single ordinary GET, and the redirect destination only ever points at a harmless sentinel host (probe-redirect-check.example) — never at a real victim. Nothing is written, brute-forced or executed, and redirects are not followed.
Will it false-positive on a site that just redirects HTTP to HTTPS or to a canonical URL?
No. A finding is raised only when the destination host exactly equals the foreign sentinel host. A redirect that stays on your own domain (HTTP→HTTPS, www canonicalisation, a relative path) never matches, so it is not reported.
How do I fix an open redirect?
Never put a user-supplied value straight into a redirect. Prefer relative paths only, or validate the destination's full host against an explicit allowlist of your own domains. Reject absolute URLs, protocol-relative //host values and backslash variants, and avoid naive checks that can be bypassed by attacker domains containing your hostname.