Redirect discrepancies can leak session tokens in browser flows

At a glance

What this is: This is a browser redirect-discrepancy analysis showing how fragment handling and redirect loops can expose session tokens embedded in URLs.

Why it matters: It matters because identity and access teams still see magic links, callback URLs, and session tokens propagated through web flows where browser behaviour can turn a safe-looking redirect into a secret exposure path.

👉 Read Ethiack's analysis of redirect discrepancies that leak secrets in URLs

Context

Sensitive data in URLs remains a governance problem because query strings, fragments, and redirect parameters are routinely copied into logs, history, analytics, and support tooling. In identity-heavy flows such as OAuth callbacks, magic links, and redemption codes, the security boundary is not just the server-side validation rule, but the full browser-to-server interpretation of the redirect path.

The article focuses on a subtle mismatch: the server believes it is issuing a path-only redirect, while the browser can transform that into a loop that never resolves cleanly. That matters to IAM and application security teams because callback handling, token redemption, and URL-based session handoffs are identity controls in practice, even when they sit outside the IAM product stack.

Key questions

Q: How should security teams stop secret leakage in browser redirect flows?

A: They should stop putting credentials in URLs, even when redirects are limited to paths. Use server-side session state or opaque references, validate browser and server URL handling separately, and test for fragment-driven loops, redirect errors, and navigation-history exposure in OAuth-style flows.

Q: Why do fragments create risk in otherwise restricted redirects?

A: Fragments are interpreted by the browser but never sent to the server, so they can change client-side navigation without changing what the backend receives. That mismatch can keep a redirect loop alive and preserve a secret in browser-visible state long enough to be exposed.

Q: What do teams get wrong about path-only redirect validation?

A: They assume that allowing only paths removes the dangerous part of redirect handling. In practice, browser behaviour, fragments, and relative URL resolution can still create loops or preserve sensitive values, so path-only validation is not a complete control for secret-bearing flows.

Q: Who is accountable when session tokens leak through callback URLs?

A: Accountability usually spans application owners, IAM teams, and security reviewers because the failure sits between identity design and browser behaviour. Callback URLs, token transport, and redirect handling should be covered in application security reviews, secure design standards, and authentication governance.

Technical breakdown

Why path-only redirects still create secret leakage risk

A path-only redirect is often treated as safer than a full URL redirect because it appears to remove the open-redirect problem. The weakness is that the browser and server do not necessarily interpret the same string in the same way. A fragment such as #x is visible to the browser but never sent to the server, so the browser can update the visible URL while the backend keeps receiving the same request. That difference is enough to create a redirect loop even when origin changes are blocked.

Practical implication: allowlisting paths is not enough if the redirect target can be influenced by fragments or other browser-only URL components.

How redirect loops become a token exfiltration path

When the browser repeatedly receives the same redirect instruction, it eventually hits its redirect limit and surfaces an error page. In the article’s example, that error state is important because the secret token remains present in the navigation history even though it was never redeemed normally. An attacker with script execution in the same origin can inspect navigation entries after the browser recovers from the error state and retrieve the token-bearing URL. The exfiltration depends on browser state, not direct page content access.

Practical implication: treat browser navigation history and redirect failure states as part of the attack surface when secrets ride in URLs.

Why fragments and callback URLs are risky in OAuth-style flows

OAuth callback flows frequently pass transient values through redirect URLs, which makes them attractive targets for leakage through logs, screenshots, referers, and client-side navigation artifacts. The fragment component is especially tricky because it is often assumed to be inert, yet it can still influence client behaviour in ways the server cannot observe. This creates a governance gap between identity protocol design and application implementation. The core issue is not just redirect validation, but secret placement in a medium that was never meant to protect it.

Practical implication: remove session tokens and redemption codes from URLs entirely, especially in callback and sharing workflows.

Threat narrative

Attacker objective: The attacker aims to recover session tokens or other URL-embedded secrets that should have been redeemed without exposure.

1. Entry occurs when an attacker supplies a fragment-bearing path or similar redirect input that the application accepts as safe.
2. Escalation happens when the browser and server diverge on URL interpretation, creating a redirect loop that preserves the sensitive token across repeated requests.
3. Impact follows when the browser exposes the token-bearing navigation state or error condition to attacker-controlled script on the same origin.

NHI Mgmt Group analysis

URL-embedded secrets are a governance failure, not just a coding flaw. Once a session token, magic link, or redemption code is placed in a URL, it inherits every downstream exposure point in the browser and surrounding tooling. The article shows that even path-only redirect validation cannot fully compensate for that design choice. For IAM and application teams, the practitioner conclusion is simple: secret placement policy matters as much as redirect validation.

Browser-specific behaviour creates a hidden identity control gap. Security reviews often validate server logic while missing client-side navigation semantics, which can turn fragments and redirects into a leakage channel. That gap sits between application security and identity governance because callback URLs are part of authentication and token lifecycle, not just routing. The practical conclusion is that identity flows need end-to-end threat modelling across the browser, not only backend allowlists.

Secret-exposure risk in redirect flows is a named concept teams should track. Browser-side redirect drift: the mismatch between what the server thinks it sent and what the browser actually does. That drift matters because it can preserve sensitive material long enough to reach logs, error pages, or navigation state. The practitioner conclusion is to treat redirect drift as a design defect in any flow that carries credentials or tokens.

Identity teams should reclassify magic links and callback URLs as sensitive authentication assets. These mechanisms often sit outside formal IAM ownership even though they control authentication outcomes and session handoff. When ownership is unclear, the likelihood of unsafe URL token handling rises. The practitioner conclusion is that identity governance must extend to application callback design and secret transport choices.

Standards such as OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 remain relevant here because secret handling is a control problem, not a language issue. The article is about human-facing web flows, but the governance lesson generalises to any system that moves secrets through URLs or browser state. The practitioner conclusion is to align application review with secret lifecycle controls, access control expectations, and secure-by-design URL handling.

What this signals

Secret exposure is increasingly a browser-and-workflow problem, not just a vault problem. IAM teams should extend review criteria to URL design, callback handling, and client-side navigation paths, because a token is only as safe as every place it can be replayed, logged, or surfaced.

Browser-side redirect drift: this is the operational signal teams should start watching for in authentication and sharing flows. If the browser can see a different URL than the server can observe, the workflow needs threat modelling, and the safest answer is usually to stop using URL-carried secrets entirely.

For practitioners

• Remove secrets from URLs Move session tokens, redemption codes, and magic-link credentials out of query strings and fragments. Use server-side state, short-lived opaque references, or back-channel exchange so browser history, logs, and referers do not become secret repositories.
• Review callback and share flows for redirect drift Test how browsers handle fragments, relative paths, and repeated redirects in OAuth and sharing workflows. Validate what the browser sees versus what the server receives, then block any flow that can preserve a token across browser-managed navigation state.
• Harden logging and analytics around identity URLs Strip or redact URL parameters before logs, screenshots, support captures, and analytics pipelines store them. This is especially important for auth endpoints, because leaked callback URLs often outlive the session they were meant to establish.
• Treat redirect error states as security-relevant Add test cases for browser error pages, redirect loops, and navigation history inspection in your application security checks. Include same-origin script access assumptions in threat models for any workflow that could surface a token-bearing URL after failed navigation.

Key takeaways

• Path-only redirects can still leak secrets when browser and server URL handling diverge.
• The exposure risk is amplified when tokens are embedded in URLs that can land in browser state, logs, or error pages.
• The practical fix is to remove secrets from URLs and review authentication flows for browser-side redirect drift.

Key terms

• Routing Drift: Routing drift is the gradual shift of requests away from the intended model path, often because policy is implicit, exceptions accumulate, or cost pressure overrides design intent. It creates governance debt by making access, reasoning depth, and tool use harder to predict and audit.
• URL-Carried Secret: Any credential, token, redemption code, or identifier embedded in a query string, path, or fragment. These values are risky because URLs are copied, logged, cached, shared, and exposed through browser state far more often than security teams expect.
• Browser Navigation State: The client-side record of where the browser has been and what URLs it has traversed. It can become security-relevant when applications rely on redirects for authentication or token redemption, because error pages and history entries may preserve sensitive locations.

What's in the full article

Ethiack's full article covers the low-level browser behaviour and proof-of-concept detail this post intentionally leaves for the source:

• Step-by-step walkthrough of the Chrome redirect-limit behaviour used to force the error state
• Concrete proof-of-concept request flow showing how the fragment preserves the token-bearing URL
• Navigation API recovery method used to inspect the URL after the redirect failure
• Implementation details of the Flask test app and the redirect chain that makes the flaw reproducible

👉 Ethiack's full post includes the proof-of-concept flow, browser error-page behaviour, and navigation recovery steps.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and machine identity security. It helps practitioners connect identity controls to the application flows where secret exposure actually happens.