An open redirect is a flaw where an application sends the user's browser to a URL taken from request input without checking it. Attackers use it so a link on your trusted domain lands on their site. The fix is to redirect only to relative paths or an allowlist of known destinations.
How does an open redirect arise?
It starts with a helpful feature. After login the app sends the user back to the page they wanted, using a parameter such as next or returnUrl. A logout flow, a link tracker or a language switcher does something similar. If the code takes that parameter and redirects to it as is, anyone can craft a link on your domain that ends up somewhere else.
CWE-601, URL Redirection to Untrusted Site, describes it: the application accepts user-controlled input that specifies a link to an external site, and uses it in a redirect. MITRE lists alternate names, including open redirect, cross-site redirect and unvalidated redirect.
OWASP's cheat sheet gives the risk in one line: because the server name in the modified link is identical to the original site, phishing attempts may look more trustworthy. It adds that forwards can also be abused to reach privileged functions that would normally be blocked by an access check.
Why does it matter if nothing is stolen from your server?
The harm lands on your users and your reputation. A person sees your real domain in the link, clicks, and arrives at a fake login page. Recipients, and some filters, tend to trust a link on a familiar domain. In some designs, redirects also play a part in stealing authorization codes during sign-in flows, which is why strict redirect matching matters in OAuth setups.
Severity depends on context: modest alone, higher when chained with another flaw. Either way they are cheap to remove, so fix them.
A constructed example
A team adds a feature: after signing in, send the user to the page in a parameter called next. The code reads the parameter and issues a redirect to its value. It works in testing with paths like the account page.
Weeks later a security review notices that any value is accepted, including a full address on another domain. The fix is small: accept only values that start with a single slash and are not protocol-relative, and map everything else to the default page. A unit test pins that behavior.
The lesson is that the feature never needed to accept full URLs. It needed a path on the same site.
How do you fix it?
Common guidance, in line with OWASP's cheat sheet, in order of preference:
- Avoid user-controlled destinations entirely. Redirect to fixed targets in code.
- If you must take input, pass an identifier or index that the server maps to a known URL, rather than the URL itself.
- If you must accept a URL, validate it against an allowlist of permitted hosts, and treat the check carefully, since parsers differ and tricks with odd syntax can slip past naive string checks.
- Prefer relative paths for same-site redirects and reject anything with a scheme or host.
- Where a redirect leaves your site on purpose, consider an interstitial page that tells the user they are leaving and shows the destination.
How to check or apply this
- Search the codebase for redirect calls that take input: parameters named next, url, return, redirect, continue, dest.
- For each, ask whether a fixed target or an ID lookup would do.
- Where a URL is needed, validate with a real URL parser against an exact allowlist, and compare the parsed host, not a substring.
- Reject values with a scheme you do not expect, backslashes and protocol-relative forms that start with two slashes.
- Add tests for accepted paths and for rejected foreign hosts and odd forms.
- In OAuth and sign-in flows, require exact registered redirect addresses and no wildcards.
- Scan your applications for the pattern on a schedule, and add it to code review checklists.
- Check forwards as well as redirects. Server-side forwards with user input can skip access checks.
Quick check
Is an open redirect a serious vulnerability?
On its own it usually carries modest severity, since the target is the user, not your server. It becomes more serious when it enables phishing at scale or is chained with other flaws, so it is worth fixing.
Does checking that the URL contains our domain make it safe?
No. Substring checks are easy to fool, for example with a lookalike host name that contains your domain. Parse the URL and compare the host exactly against an allowlist.
Sources
- CWE-601: URL Redirection to Untrusted Site (Open Redirect)
- OWASP Cheat Sheet: Unvalidated Redirects and Forwards
- OWASP Cheat Sheet: Input Validation
Last reviewed: 18 October 2026.
