Open redirects after login or OAuth callbacks

Steps

1. Find post-login and OAuth callback handlers that read next, return_to, redirect, redirect_uri, or url from the query string.
2. On your own app, try a callback with an absolute external URL and a protocol-relative //example.com target. Confirm the app does not forward the browser there.
3. Allow only relative in-app paths from a fixed list, or absolute URLs whose host matches an exact allowlist—parsed with a real URL parser, not startsWith or contains.
4. For OAuth, register exact redirect_uri values with the provider and compare byte-for-byte. Send the same redirect_uri to the token endpoint. Use the state parameter bound to the user session (and PKCE for public clients).
5. Remove leftover /go?url= or marketing redirect endpoints that forward arbitrary URLs.
6. If you must send users off-site, show an interstitial that displays the full destination before they continue.

Why it matters

PortSwigger's OAuth guidance says providers should whitelist redirect_uris with strict exact matching, and clients should send redirect_uri to both authorize and token endpoints and use state. OWASP documents how an open redirect on your domain can be chained to steal OAuth authorization codes when redirect_uri checks are too loose.

Sources

PortSwigger Web Security Academy: How to prevent OAuth authentication vulnerabilities — https://portswigger.net/web-security/oauth/preventing

OWASP: Open Redirect — https://community.owasp.org/attacks/open_redirect

Related patterns

• JWTs or session tokens stored in localStorage
• CORS that trusts any origin (and sends cookies)
• API routes with no auth check