What is an Open Redirect?

An open redirect occurs when an application takes a redirect destination from controllable input without restricting it to an approved location. A link on the genuine corporate domain can thereby send visitors directly to an external site. Common parameter names include next, returnUrl, continue and redirect.

How does an open redirect work?

After login or logout, an application may return to the previous page. If the client supplies a full URL, an attacker can insert their domain and distribute the prepared link. The browser first visits the legitimate site and then follows an HTTP redirect or client-side navigation. Variants appear in JavaScript, meta refresh, routers, error pages and chains of multiple redirects.

Why is a redirect security-relevant?

An ordinary redirect does not directly compromise the server. Risk depends on context, trust in the domain and potential chaining. An interstitial warning can inform users but does not correct unsafe destination selection.

What is different in OAuth and SSO?

OAuth and OpenID Connect use registered redirect URIs to which the authorization server returns after login. An overly broad, prefix-checked or itself open URI can expose authorization codes or tokens to an attacker path. Validation must follow the protocol and provider's exact requirements; a general open redirect inside a client may make the chain worse. Sensitive values should not appear unnecessarily in URLs, referrers or logs.

Why do simple URL checks fail?

A string can start with https://company.example but point to company.example.attacker.tld. Other edge cases include user information before @, protocol-relative URLs with //, backslashes, encoded separators, international domain names, ports, embedded URLs and repeated decoding. Proxy, framework and browser parsers may interpret the same value differently.

How are redirects implemented safely?

1. Prefer fixed targets: Map a short identifier such as dashboard to a known internal route server-side.
2. Constrain relative paths: Permit paths in the application only and reject protocol-relative and absolute values.
3. Parse components: If external targets are needed, compare scheme, normalized host and port exactly with a small allowlist.
4. Do not trust headers: Use host and proxy headers for URL generation only from trusted infrastructure.
5. Register authentication targets: Specify OAuth and SSO redirect URIs as exactly as possible.
6. Log redirects: Detect unusual external targets without recording tokens or personal data.

Code example: destination identifiers instead of arbitrary URLs

Vulnerable:

return redirect($request->query('next'));

Safer:

$destinations = [
    'account' => route('account.index'),
    'orders' => route('orders.index'),
];

$target = $destinations[$request->query('next')] ?? route('home');
return redirect()->to($target);

If external destinations are necessary, use a URL-parser-based allowlist covering scheme, exact host and, where relevant, port. Prefix and substring comparisons are not sufficient.

How are they tested?

Testers inventory redirects in login, logout, errors, invitations and email links. They exercise absolute, relative, protocol-relative, encoded and parser-sensitive destinations and redirect chains. The browser's actual final destination matters, not only the status code. OAuth and SSO flows are tested with test accounts and controlled callbacks without exposing real tokens.