Open Redirect Definition Open redirect occurs when an application redirects users to attacker-controlled destinations based on untrusted input without strict destination validation. Why it matters Open redirects often look low impact alone, but they become powerful when chained with phishing, OAuth flows, login redirects, token leakage, CSP bypasses, or trusted-domain allowlists. The trusted domain performs the redirect, so users and systems may treat the destination as legitimate. How it works Open redirect has 3 parts: Redirect parameter. next, url, redirect, returnTo, continue, or similar. Server/client redirect behavior. HTTP Location, JavaScript assignment, meta refresh, or framework routing. Weak validation. The application accepts arbitrary or bypassable destinations. Payload-shaped example: GET /login?next=https://evil.example HTTP/1.1 Host: app.example.test The bug is not redirecting after login. The bug is letting untrusted input choose a destination outside the allowed trust boundary. Techniques / patterns Attackers test: redirect parameters in login, logout, SSO, password reset, and invite flows absolute URLs, protocol-relative URLs, and encoded URLs path confusion: //evil.example, /\evil.example, %2f%2fevil.example userinfo tricks: https://app.example.test@evil.example subdomain and suffix confusion OAuth redirect and callback chains Variants and bypasses Open redirects appear in 5 contexts. 1. Login return redirect The app redirects after authentication to an arbitrary destination. 2. OAuth redirect chain A trusted redirect endpoint is used to bypass OAuth redirect URI restrictions. 3. Client-side redirect JavaScript reads a URL parameter and navigates the browser. 4. Domain validation bypass Suffix, substring, userinfo, encoding, or scheme tricks bypass allowlists. 5. Token leakage redirect Tokens or codes in URLs are forwarded to attacker-controlled destinations. Impact Ordered roughly by severity: OAuth or SSO compromise chain. Redirects bypass strict callback rules. Credential phishing. Trusted domains lend credibility to phishing links. Token or code leakage. Sensitive URL fragments or query parameters leak. Access-control bypass chains. Redirect behavior interacts with allowlists or SSRF filters. Brand abuse. Trusted links send users to malicious content. Detection and defense Ordered by effectiveness: Use server-side destination IDs instead of raw URLs. Map next=dashboard to a known internal route rather than accepting arbitrary URLs. Allow only relative paths when possible. Most post-login redirects do not need external destinations. Validate destinations with URL parsers and exact allowlists. Compare canonical scheme, host, and path; avoid substring checks. Keep OAuth redirect URIs exact and avoid redirect-chain endpoints. OAuth clients should not allow trusted open redirectors as callback paths. Do not place secrets in URLs. This reduces damage if redirects or referrers misbehave. What does not work as a primary defense Substring allowlists. trusted.com.evil.example is not trusted. Checking only URL starts-with. Encoding and userinfo can bypass naive checks. User confirmation pages alone. They reduce phishing but do not fix unsafe redirect logic. Assuming same-domain redirectors are harmless. Chains matter. Practical labs Use owned apps or labs. Find redirect parameters rg -n "redirect|returnTo|next|continue|callback|url" src routes public Review where user-controlled destinations are accepted. Test absolute destination curl -i 'https://app.example.test/login?next=https://example.org' Check whether Location points outside the intended domain. Test parser confusion curl -i 'https://app.example.test/login?next=//example.org' curl -i 'https://app.example.test/login?next=https://app.example.test@example.org' Use a controlled destination in labs. Practical examples Login accepts next=https://evil.example. Password reset redirects to a user-controlled URL after completion. OAuth callback allowlists a path that is itself an open redirect. JavaScript redirects based on location.hash. A support link uses a redirector that can target arbitrary domains. Related notes oauth-security auth-flaws session-management ssrf Recon to Testing Handoff Suggested future atomic notes oauth-redirect-uri-bypass client-side-open-redirect url-parser-confusion phishing-link-hardening safe-return-url-design References Foundational: OWASP Unvalidated Redirects and Forwards Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html Testing / Lab: PortSwigger OAuth authentication — https://portswigger.net/web-security/oauth Foundational: OWASP WSTG latest — https://owasp.org/www-project-web-security-testing-guide/latest/ ← PreviousOAuth SecurityNext →OWASP Top 10 Explore nearby notes Web SecurityAuthentication FlawsAuthentication flaws are weaknesses in how an application verifies identity. They include weak login logic, user enumeration, broken MFA flows, password reset... Web SecurityBot Detection SignalsBot detection signals are the observable clues a web application or edge service uses to classify traffic as human, benign automation, suspicious automation, or... Web SecurityBroken Access ControlBroken access control happens when an application fails to enforce what a caller is allowed to access or do. Web SecurityBusiness Logic VulnerabilitiesBusiness logic vulnerabilities are flaws in the intended workflow, assumptions, invariants, or rule design of an application, where the system behaves as coded but... Web SecurityClickjackingClickjacking is a UI redress attack where an attacker embeds a target page in a frame and tricks the user into clicking or typing into the real target UI while... Web SecurityCommand InjectionCommand injection occurs when an application builds an operating-system command from attacker-controlled input and executes it through a shell or process API...