Open Redirect

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Unvalidated Redirect and Forward
Typical Severity Medium
OWASP A01:2021 – Broken Access Control (formerly A10:2013 – Unvalidated Redirects and Forwards)
CWE CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Also known as Unvalidated Redirect, Open Redirection, Arbitrary Redirect
Affected systems Web applications with login flows, OAuth endpoints, URL shorteners, and any feature using a redirect or return-URL parameter
Common parameters redirect, redirect_uri, return, returnTo, next, url, target, dest, goto, continue

Overview

An open redirect is a vulnerability in which a web application uses attacker-supplied input to construct a destination URL for an HTTP redirect response (status codes 301, 302, 303, 307, or 308) without verifying that the destination is within a trusted set of locations. Because the redirect originates from a legitimate, trusted domain, victims and security controls (email filters, browser warnings) are less likely to flag the initial link as malicious.

Sensagraph automatically detects open redirect vulnerabilities by probing redirect parameters for external destination acceptance.

How it works

Open redirects arise whenever user-controlled data is passed directly into a redirect mechanism. The typical attack chain is:

  1. Craft the URL: The attacker identifies a redirect parameter on a trusted site, e.g. https://example.com/login?next=https://evil.com/phish.
  2. Distribute the link: The attacker sends the crafted URL via email, social media, or chat. The visible domain is example.com, making the link appear legitimate.
  3. Victim clicks and is redirected: The server reads the next parameter without validation and issues an HTTP 302 response to https://evil.com/phish.
  4. Attacker achieves goal: The victim arrives at a phishing page, credential harvester, or malware download, believing they were redirected by a trusted site.

Beyond phishing, open redirects are commonly chained with other vulnerabilities:

  • OAuth token theft: When an OAuth 2.0 authorization server does not strictly validate redirect_uri, an open redirect on the client application can be used to exfiltrate authorization codes or access tokens via the Referer header or URL fragment leakage.
  • SSRF facilitation: In some architectures, a server-side redirect to an attacker-controlled URL can enable Server-Side Request Forgery by causing the server itself to fetch the attacker's URL.
  • Security control bypass: Allowlist-based URL filters that check only the initial URL (before following redirects) can be bypassed using an open redirect on a trusted domain.
  • Cross-Site Scripting (XSS) via javascript: URIs: If the redirect destination is not sanitized, some implementations accept javascript: scheme URLs, leading to XSS when the browser processes the redirect target.

Common vulnerable code patterns include:

  • PHP: header("Location: " . $_GET['url']);
  • Java/Spring: return "redirect:" + request.getParameter("next");
  • Node.js/Express: res.redirect(req.query.returnTo);
  • Python/Django: return HttpResponseRedirect(request.GET.get('next')) without validation

Business impact

While open redirects are often rated medium severity in isolation, the practical business impact can be significant:

  • Phishing and credential theft: Users deceived by a redirect from a trusted domain may submit credentials to an attacker-controlled site, leading to account takeover.
  • Brand and reputational damage: Customers associate the phishing attack with the legitimate brand, eroding trust even when the organization is a victim rather than the cause.
  • Regulatory and compliance exposure: Credential theft facilitated through the organization's own infrastructure may trigger breach notification obligations under GDPR, HIPAA, PCI-DSS, or similar frameworks.
  • Token exfiltration in OAuth flows: A successful OAuth redirect attack can lead to full account compromise without requiring the user's password.
  • Malware distribution: Attackers may redirect users to drive-by download pages, making the organization's domain an unwitting vector for malware delivery.

How to fix it

  1. Avoid user-controlled redirect destinations entirely: The most robust defense is to redesign flows so the redirect destination is never derived from user input. Instead, use server-side mappings (e.g., a numeric action ID that maps to a hardcoded URL).
  2. Implement a strict allowlist: If a dynamic redirect is necessary, validate the destination against a hardcoded allowlist of permitted domains or paths. Reject any destination not on the list.
    • Example (Python): ALLOWED = {'https://example.com/dashboard', 'https://example.com/profile'}; if url not in ALLOWED: url = '/default'
  3. Validate relative paths only: Restrict accepted redirect values to relative paths (starting with / but not //) within the same origin. Reject absolute URLs with a scheme and host component entirely.
  4. Enforce strict redirect_uri matching in OAuth: Per RFC 6749 §3.1.2.2, authorization servers MUST require an exact match (or registered prefix match) of the redirect_uri. Do not perform open matching or partial URL comparison.
  5. Apply the javascript: URI blocklist: Explicitly reject any redirect destination whose scheme is not http or https.
  6. Warn users before external redirects: If redirecting outside the application's own domain is a necessary business feature, display an interstitial warning page informing the user they are leaving the site, rather than silently forwarding them.
  7. Add automated test coverage: Include open redirect test cases in CI/CD pipelines to prevent regressions when redirect logic changes.

References

Frequently asked questions

Open redirects are typically rated medium severity on their own, because exploiting them requires social engineering — the victim must click the crafted link. However, severity escalates to high or critical when chained with OAuth flows (enabling token theft), when the application is a high-value target such as a bank or identity provider, or when the redirect parameter accepts javascript: URIs that trigger XSS.

Yes. While most open redirects occur in GET parameters because links are easily shareable, redirect destinations can also be passed in POST body parameters, HTTP headers (such as Referer or a custom header), or cookies. The mechanism and impact are identical regardless of HTTP method.

No. Host header validation is a separate control (primarily relevant to Host header injection). Open redirect validation must be applied specifically to the redirect destination URL extracted from the request parameter, cookie, or body — not to the Host header of the incoming request.

An open redirect causes the client's browser to be redirected to an attacker-controlled URL. SSRF causes the server itself to make an HTTP request to an attacker-controlled URL. Open redirects can sometimes be used as a stepping-stone to achieve SSRF if the server follows redirects when making outbound requests (e.g., a server-side URL fetcher that follows 302 responses).

Per RFC 6749, the authorization server must require exact registration of redirect_uri values. During the authorization request, the server must compare the supplied redirect_uri against the pre-registered value using exact string matching or a strictly defined prefix match. Wildcard matching or substring matching in redirect_uri validation is a common source of open redirect vulnerabilities in OAuth implementations.