OAuth Token Leakage Bug Bounty 2026 — Find, Exploit & Report Token Exposure | Bug Bounty Day 32 of 60

The two OAuth flows and where each leaks

When I begin an OAuth review, I first identify which flow the application uses. Two flows you’ll encounter in training and older applications are the authorization code flow and the implicit flow. The authorization code flow sends a short-lived authorization code back to the client, which then exchanges it for tokens. In a server-side application, that exchange can happen on the back end; in a browser-based public client, it may happen in the browser with PKCE. Either way, the access token should not be placed in the authorization redirect URL. The implicit flow is the older approach: the server redirects to the client with the access_token directly in the URL fragment. It was designed for single-page apps before PKCE existed. You may still find it in legacy systems, and its fragment-based token delivery deserves careful inspection.

Here’s how I think about the difference. With implicit flow, I focus on where the browser stores and exposes the token. With authorization code flow, I examine redirect URI matching, code binding, PKCE, and CSRF protection. A missing state value is not automatically exploitable—some clients use other binding mechanisms, including correctly validated OIDC nonce values or PKCE—but I always verify that the response belongs to the login attempt that initiated it.

How I map an OAuth assessment before testing

I don’t begin by changing random parameters. First, I map the normal login journey so I know which component is responsible for each decision. In a typical flow, the browser starts at the application, the application sends the browser to the authorization server, the user authenticates and grants permission, and the authorization server sends the browser back to the registered callback. The client then validates the response and obtains or uses the token. If I don’t understand that baseline, I can’t reliably tell whether a modified request has exposed a security flaw.

I also identify the client type. A confidential server-side client can authenticate to the token endpoint using a client secret or another approved method. A public client, such as a browser-only application or mobile app, cannot safely keep a static client secret. That’s one reason PKCE matters: it binds the authorization code to the client instance that initiated the flow. I compare the application’s behavior with the flow and client type it actually implements.

Tokens in URLs — the implicit flow exposure

When I spot response_type=token, I know to inspect the final redirect in the browser. The URL looks like this: https://app.example.com/callback#access_token=eyJhbGciOi...&token_type=bearer&expires_in=3600. Notice the #. Everything after it is a URL fragment. Browsers do not send that fragment in HTTP requests or Referer headers. That distinction matters because it changes which leakage paths are actually possible.

Here’s the important catch I teach students: JavaScript running on the callback page can read window.location.hash. That means an untrusted script executing in that page’s context could access a fragment-delivered token. I inspect the page’s scripts, browser behavior, and token cleanup, but I don’t report every third-party script as an automatic leak. I look for evidence of actual exposure. Also remember: the browser does not send fragments to the web server, so ordinary server access logs cannot capture them directly. A client-side logger or script could explicitly transmit the fragment, and that’s the behavior I’d need to prove.

Token exposure: what counts as a real finding?

One mistake I see beginners make is treating every appearance of access_token as proof of account takeover. It isn’t. I separate an indicator from an exploitable disclosure. A token-like string in a harmless example, a redacted debug message, or a value that never leaves the test environment is not enough. I want to establish what credential was exposed, who could obtain it, how long it remained valid, what permissions it carried, and whether it could actually be used.

For example, imagine my own test account completes a login and the callback URL contains a bearer token in its query string. I inspect the browser’s subsequent requests. If a request to an unrelated analytics service includes that callback URL in its Referer header, I have evidence that the URL was disclosed to that destination. I still need to determine whether the token was valid, whether the recipient could access it, and what scopes it grants. I redact the value immediately and never paste a live token into a public report.

The Referer header leakage attack

Now let’s look at a different leakage path: the Referer header. I always separate query strings from fragments when teaching this. A fragment is not included in Referer headers. But if application JavaScript copies a fragment token into a query string or another outbound request, the token can be exposed. My job is to trace the actual request, not assume the browser sends fragments automatically.

The easier case to investigate is a token placed directly in a query string. I load the callback page through Burp, inspect subsequent requests, and check whether any Referer actually includes the sensitive value. Modern browsers commonly default to strict-origin-when-cross-origin, which strips the path and query from cross-origin referrers. Same-origin requests and permissive policies can behave differently. That’s why I verify the observed headers before writing a finding.

A practical Referer investigation in Burp

Here is the sequence I use when I suspect a callback URL is being disclosed. I complete the OAuth flow with my own account, keep Burp Proxy history open, and identify the callback response. Then I inspect requests initiated by that page: scripts, images, fonts, analytics beacons, API calls, and navigation to external sites. For each cross-origin request, I inspect the Referer header and compare it with the callback URL.

The browser’s Referrer-Policy controls how much of the source URL is sent. A policy such as strict-origin-when-cross-origin normally sends only the origin on cross-origin requests, while same-origin requests can include more URL detail. A policy of no-referrer suppresses the header. I check the actual browser request rather than guessing from the response header alone. Browser defaults and policy behavior can vary by context, so the captured request is my evidence.

Redirect_uri manipulation

This is one of the OAuth checks I take most seriously, although the severity depends on whether a real exploit chain works. I start with the redirect URI registered for the client and ask whether the authorization server enforces the expected matching rules. When a user authorizes access, the server redirects to that URI with the authorization code or token. If a server accepts an unauthorized destination, a code or token could be delivered somewhere unintended. Whether that leads to account access depends on additional protections such as PKCE, client authentication, code binding, and token scope.

In a lab, I test several common validation mistakes. In vulnerable implementations, servers may check only that the redirect_uri starts with the registered domain, so https://legitimate.com.evil.com/callback passes. Some check for the domain as a substring anywhere in the URL, so https://evil.com/page?url=https://legitimate.com passes. Some accept any subdomain of the registered domain, so if you can register evil.legitimate.com or find a subdomain takeover, that may create another path to investigate. Some are more subtle — they validate the URI correctly but accept open redirects on the client, so https://legitimate.com/redirect?to=evil.com gets you to evil.com after the code lands at legitimate.com.

My redirect URI testing checklist

When I test redirect URI validation, I work methodically and change one element at a time. The expected behavior is strict matching against a pre-registered URI. I record whether the authorization server rejects a mismatch, normalizes it, or redirects somewhere unexpected. I do not treat a strange-looking accepted value as a vulnerability until I can demonstrate that the authorization response reaches an unintended destination.

An open redirect on the application domain is a separate weakness. It becomes relevant to OAuth when the two behaviors can be chained and the authorization response is exposed as a result. If the code reaches a legitimate callback and the application then redirects elsewhere without carrying the code, that is not the same impact as code disclosure.

State parameter — the OAuth CSRF

When students ask me why state matters, I start with the login session itself. The OAuth state parameter is a nonce — a random, unguessable value the client generates before the authorization request and validates after the redirect. Its purpose is to prevent CSRF attacks on the OAuth flow. If the state is missing or not validated, an attacker can force a victim to complete an OAuth authorization that connects the victim’s browser session to the attacker’s account. The classic impact: victim’s browsing data, purchases, or private information gets associated with the attacker’s account. Or, in the account-linking scenario, the attacker links a victim’s account to the attacker’s OAuth identity — which is an account takeover.

Here’s how I teach this test: capture a complete login flow with your own account, then compare the initiating request with the callback. Try removing or changing state in a controlled lab and observe what the client does. The authorization server is not generally responsible for requiring or validating a client’s state; the client must bind the response to its own initiated session. I also check whether another mechanism, such as a properly verified OIDC nonce or PKCE-based binding, provides the relevant protection. I only call it exploitable when I can demonstrate the resulting session confusion using accounts I control.

How I distinguish missing state from exploitable login CSRF

The presence of a state parameter is a widely used way to bind an authorization response to the browser session that initiated it. But simply removing it from a request and seeing the authorization server issue a code does not prove a vulnerability. The authorization server may simply echo the value it receives; the client application is responsible for checking that the response matches the pending login transaction.

To demonstrate login CSRF safely, I use two accounts that I own in an isolated lab. I initiate a flow with one account, then test whether the callback can be attached to a different browser session or unrelated login attempt. I observe which identity the application ultimately associates with the browser. I also check for other binding controls, such as OIDC nonce validation and PKCE, rather than assuming a missing state parameter tells the whole story.

PKCE — what it fixes and what it doesn’t

When I explain PKCE—Proof Key for Code Exchange, pronounced ‘pixie’—I describe it as proof that the client redeeming an authorization code knows a secret generated when the flow began. The client generates a random code_verifier, hashes it to create a code_challenge, and sends the challenge with the authorization request. When exchanging the code for a token, the client sends the original code_verifier. The server verifies that hash(code_verifier) == code_challenge. In a correctly implemented flow, simply possessing an intercepted code should not be enough to redeem it without the matching verifier.

PKCE isn’t a replacement for strict redirect URI validation, and it doesn’t solve implicit-flow token exposure. But it does substantially reduce the risk of redeeming an intercepted authorization code—even when a redirect problem exists—because the attacker ordinarily lacks the verifier. I look for code_challenge_method=S256, then verify that the token endpoint rejects a missing or incorrect code_verifier. The plain method is weaker because the challenge equals the verifier; however, seeing plain alone doesn’t prove an attacker can obtain the verifier or redeem a code. I report the demonstrated impact, not just the parameter value.

A simple PKCE walkthrough

I explain PKCE as a two-part proof. At the start of the flow, the client creates a high-entropy random code_verifier. It derives a code_challenge from that verifier and sends the challenge to the authorization endpoint. Later, when the client redeems the authorization code, it sends the original verifier to the token endpoint. The server derives the challenge again and compares it with the value stored for that authorization request.

For the recommended S256 method, the relationship is conceptually:

When I validate this in a lab, I check both sides of the exchange. The authorization request should contain the challenge and method. The token exchange should fail if the verifier is missing or incorrect, and succeed only with the verifier associated with that code. I do not publish actual verifier values or authorization codes in a report.

OAuth versus OpenID Connect: don’t mix up the tokens

OAuth 2.0 is an authorization framework. It allows a client to obtain delegated access to a resource. OpenID Connect (OIDC) builds an authentication layer on top of OAuth 2.0 and commonly introduces an id_token that describes the authentication event. An access token is intended for a resource server; an ID token is intended for the client to validate the user’s authentication. They are not interchangeable.

When I see openid in the requested scope or an id_token in the response, I check whether the application validates the ID token’s signature, issuer, audience, expiry, and nonce where applicable. A JWT-shaped string is not automatically trustworthy just because it decodes successfully. Decoding reveals claims; it does not verify the signature.

Writing the report that pays

When I help students write OAuth reports, I insist on one thing: make the evidence easy to follow. The technical finding — “redirect_uri accepts any domain” — sounds serious to security professionals but abstract to a programme’s triage team. The triager needs to understand what you observed, what protections were present, and what you could actually demonstrate. For redirect_uri manipulation, that chain is: attacker crafts URL → victim clicks → authorization server redirects to attacker’s server → attacker exchanges code for token → attacker makes API calls as victim. I document each verified step with sanitized screenshots and never claim token redemption or account takeover unless my controlled test proves it.

What I want you to take away from Day 32

OAuth testing is not about collecting a long list of unusual parameters. It is about understanding the trust relationship between the browser, the client application, and the authorization server. I start with a normal flow, identify the client and response type, and then test one control at a time: redirect URI validation, state binding, PKCE, and token handling. Most importantly, I prove the consequence with my own test account before I describe the impact.

If you remember one thing from this lesson, remember this: an OAuth weakness becomes a strong bug bounty finding when you can show exactly how the trust boundary fails, who can exploit it, and what access that failure actually provides.