Open Redirect Defense

Open redirect defense

A redirect that trusts its ?next= value lets an attacker forge a link on your trusted domain that lands the victim on theirs. It fuels phishing that survives a careful glance at the hostname, and in OAuth flows it delivers authorization codes to the wrong party. The fix is not smarter parsing: it is declining any destination you did not approve in advance.

Method

1. Prefer a redirect map to accepting URLs at all. Where you can, carry a short key (?next=inbox) and resolve it against a server-side table of allowed paths. A parameter that never holds a URL cannot hold a hostile one.
2. If you must accept a URL, allowlist the host after parsing. Parse the target with a real URL parser, then confirm the host matches an explicit list of your domains by exact comparison. Never judge with startsWith or a substring: https://yoursite.com.evil.com and https://evil.com/?u=yoursite.com both beat prefix checks.
3. Default to relative paths only. When the feature only moves within your app, accept a target that begins with a single / and reject the rest. Block //evil.com and /\evil.com, which browsers read as protocol-relative jumps to another origin.
4. Reject dangerous schemes outright. Permit only http and https. Refuse javascript:, data:, and mailto:, which turn a redirect into script execution or a different trap entirely.
5. Normalize before comparing. Decode percent-encoding, fold backslashes to forward slashes, strip whitespace and control characters, and lowercase the host once, so %2F%2Fevil.com and mixed-case tricks cannot slip past a check that ran against the raw string.
6. Pin OAuth and SSO callbacks to exact registered URIs. Match the full callback URI against the pre-registered set with no wildcard on host or path. A loose callback allowlist is precisely how authorization codes get stolen.

Checks

• Does ?next=https://evil.com land on your domain or an error, never on evil.com?
• Are //evil.com and /\evil.com treated as external and refused?
• Is the host matched by exact allowlist entry, not startsWith or includes?
• Are OAuth callback URIs matched exactly, with no wildcard host or path?

Boundaries

This governs where a redirect may send the browser, nothing else. It does not authenticate the user or protect the session that outlives the hop (see oauth-flows for callback trust). A domain you control that also hosts user content can still be an unsafe target: allowlisting the host is necessary, not always sufficient.