Open redirects: validating where a next parameter may send the user

What it is

Login pages, logout handlers, language switchers and OAuth callbacks commonly take a next, returnUrl or redirect parameter and send the browser there afterwards. Used unchecked, https://example.org/login?next=https://evil.example/ is a link on your domain that ends on the attacker's page; the OWASP cheat sheet notes that because the server name in the link is the trusted one, the phishing attempt looks more trustworthy. The cheat sheet also covers forwards: a server-side dispatch to a path taken from the request can bypass access control.

Why it matters

Open redirects are of limited use on their own but are a building block: they lend your domain's reputation to phishing mail, RFC 9700 describes how an open redirector on a client can be used to leak authorisation codes and tokens, and they defeat "links to our domain only" rules in mail filters and content policies.

How to apply

• Prefer no user-supplied destination: keep the intended return location in the session, or map a short identifier to a URL server-side (the cheat sheet's first recommendations), watching for enumeration of identifiers.
• If a URL must be accepted, use an allowlist, which the cheat sheet prefers over a denylist: accept only relative paths that begin with a single / (reject //host, /\host and anything containing a scheme), or parse it and compare scheme and host with an explicit list of allowed origins.
• Parse with the platform's URL parser and then validate the parts. The Python documentation states that urlsplit() and urlparse() do not validate input, may return empty components instead of raising, and that code with security implications should check whether the scheme, host and path make sense before trusting them.
• Normalise before comparing: decode percent-encoding once, lower-case the host, strip whitespace and control characters, reject userinfo forms (user@host).
• In OAuth flows compare redirect_uri with registered values by exact matching, not by prefix or pattern: RFC 9700 advises exact redirection URI matching and states that web servers hosting redirection URIs must not expose open redirectors.
• Keep a test list of bypass shapes (//evil.example, https:evil.example, /\evil.example, https://example.org.evil.example, https://example.org@evil.example) and assert each is rejected.

Pitfalls

Checking startswith("https://example.org"), which matches https://example.org.evil.example. Validating before decoding and redirecting after. Allowing any subdomain when one subdomain hosts user content. The validator's parser and the browser's parser may disagree: the Python documentation notes that its functions incorporate aspects of both the WHATWG URL Standard and RFC 3986 without being compliant with either, so test what the browser does with the accepted value, not only what the server thinks it means.