Redirect discrepancies can leak session tokens in browser flows

At a glance

What this is: Ethiack examines how redirect discrepancies between browser and server handling can leak session tokens when sensitive data is embedded in URLs.

Why it matters: It matters because IAM and application teams still rely on URL-based flows for callbacks, redemption links, and session handoff, where parsing quirks can turn a control into a disclosure path.

Context

URLs are not a safe place for secrets, even when an application narrows redirect inputs to paths instead of full destinations. The core governance gap is a false sense of safety: browser behavior, server-side validation, and client-visible URL state do not always move in lockstep.

In this case, the identity angle is direct because the values at risk are session tokens and redemption links, which function as temporary authentication artefacts. When those artefacts ride in query strings or fragments, URL handling quirks can expose them outside the intended trust boundary.

Path-only redirects reduce one class of open-redirect abuse, but they do not remove the underlying problem of secrets living in browser-visible locations. That makes this a practical identity and application security issue, not just a web edge case.

Key questions

Q: What breaks when session tokens are carried in redirect URLs?

A: The trust boundary breaks because browser-visible URL state can diverge from what the server receives, especially when fragments or repeated redirects are involved. That divergence can preserve a sensitive token long enough for browser history, error pages, or navigation state to expose it. The safe design choice is to keep authentication artefacts out of URLs entirely.

Q: Why do path-only redirects still leak secrets in browser flows?

A: Path-only validation limits open redirects, but it does not eliminate browser behavior that rewrites visible URL state or treats fragments differently from the server. If a secret is already in the URL, the browser can continue to surface it during navigation retries or error handling. The underlying problem is secret placement, not just redirect destination format.

Q: What are the signs that a redirect flow is unsafe for identity tokens?

A: Warning signs include tokens in query strings, fragments, or callback parameters, especially where the flow can be retried or redirected more than once. Another indicator is that the application relies on browser navigation to complete token redemption instead of a server-side exchange. Those patterns raise the likelihood of URL leakage and replay risk.

Q: How should IAM teams design callback flows to avoid URL-based token exposure?

A: Use callbacks that exchange a non-sensitive code for the real session server-side, then invalidate the code immediately after use. Keep the browser-facing URL free of secrets, set strict allowlists for any redirect target, and test how major browsers handle fragments, history, and error conditions before release.

Technical breakdown

Why browser and server URL handling diverges

Browsers and servers do not interpret every URL component the same way. The fragment portion after a hash symbol is browser-visible but is not sent in the HTTP request, while the server only sees the request path and query string. That mismatch creates a state where the browser believes the URL changed, but the server sees the same request again. In redirect flows, that difference can repeat the same response until the browser hits its redirect limit. Practical implication: treat browser-visible URL state as untrusted when it can carry any secret or redemption value.

Practical implication: Do not allow sensitive values to persist in browser-visible URL components during redirect flows.

How path-only redirects can still become secret leakage paths

A path-only redirect check is stronger than accepting arbitrary external URLs, but it still leaves room for manipulation when the redirect target is constructed from user-controlled input. If the application reflects that input into a Location header and the browser rewrites the visible URL during navigation, a redirect loop can form without ever leaving the origin. The application may think it is only handling an internal path, yet the browser can keep reissuing the same request until an error page or alternate navigation state exposes the secret. Practical implication: path allowlisting is necessary, but it is not a substitute for removing secrets from redirect-dependent URLs.

Practical implication: Allowlist redirect paths, but redesign flows so secrets are never embedded in redirect parameters.

Why redirect limits matter to token exposure

Most browsers enforce a redirect cap to prevent infinite navigation loops. That safeguard can be turned into a disclosure mechanism when the looping URL itself contains a session token, magic link, or redemption code. Once the cap is reached, the browser may render an error page instead of the intended destination, and browser-side state can retain enough URL information to be inspected after same-origin navigation resumes. The risk is not the error page alone, but the fact that the sensitive artefact survived inside the URL long enough to reach that state. Practical implication: any token that can survive multiple redirects is already overexposed.

Practical implication: Design callbacks so tokens expire before navigation retries can amplify exposure.

Threat narrative

Attacker objective: The attacker aims to recover a session token or equivalent redemption secret from a browser-mediated redirect flow.

1. Entry occurs when the attacker controls a path-based redirect parameter in a browser flow that handles a sensitive session token or redemption link.
2. Credential exposure happens because the token is carried in the URL, where browser and server parsing differ and the fragment can trigger repeated redirects.
3. Impact occurs when the browser reaches its redirect limit and the URL containing the token remains recoverable through browser state or error-page navigation artifacts.

Breaches seen in the wild

• Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

URL-resident secrets remain an identity governance failure, not just a web bug. Session tokens, redemption codes, and magic links are authentication artefacts, so their placement in URLs collapses the boundary between transport mechanics and identity control. Once a secret is visible to the browser, logs, history, analytics, and redirect state can all become accidental distribution channels. Practitioners should treat any URL-based secret as a design defect, not a harmless convenience.

Path-only redirect validation can create a false safety signal. Narrowing a redirect target from full URL to path reduces one attack class, but it does not eliminate browser-side navigation quirks or fragment handling differences. The governance gap is assuming that internal-only destinations are automatically safe when the real issue is whether a secret survives the navigation process. Practitioners should evaluate redirect design against browser behavior, not just server validation.

Redirect error handling is part of secret governance. When browser error states can preserve or reveal URL state, the redirect limit becomes a security boundary rather than a mere usability issue. That means callback and redemption flows need explicit controls over secret lifetime, not just input validation. Practitioners should remove secrets from URLs before browser retries and error handling can amplify exposure.

Ephemeral credentials need ephemeral transport, too. Short-lived tokens are still exposed if they travel through browser-visible URL paths, because short lifetime does not cancel broad observability. This is especially relevant for IAM teams that rely on OAuth callbacks, magic links, and verification links. Practitioners should align token transport with the same discipline they apply to token issuance.

Browser parsing quirks are now part of the attack surface for delegated identity flows. OAuth-style redirects, support links, and redemption journeys often assume the browser and server will agree on URL state, but that assumption is not guaranteed. The article reinforces a wider identity lesson: flows that depend on URL continuity should be designed to fail closed when browser state diverges. Practitioners should review any callback flow that treats the browser as a trusted carrier of secrets.

What this signals

Redirect flows should now be treated as identity-bearing attack surfaces. Any design that places a session token, verification code, or one-time link into a browser URL inherits the browser’s parsing rules as part of the control surface. That shifts the governance question from “is the redirect internal?” to “does the secret survive the browser journey?”

URL-based secrets create a hidden coupling between application security and IAM. The same value that proves identity can also leak through logs, history, screenshots, and retry loops if it is exposed in the wrong transport. Practitioners should assume that browser-visible state is durable enough to outlive the intended secret window unless they design it out.

Fragment handling and redirect limits are operational details that security teams can no longer ignore. They can transform a seemingly harmless path redirect into a disclosure path when sensitive values remain embedded in the URL. The practical response is to move secret transfer out of navigation altogether and into controlled server-side exchanges.

For practitioners

• Remove secrets from redirect URLs Move session tokens, redemption codes, and magic links out of query strings and fragments, and pass only non-sensitive state through redirects. Replace URL-embedded secrets with server-side session references or one-time handoff identifiers that cannot be replayed from browser history or error pages.
• Allowlist redirect destinations by exact path Treat user-controlled redirect inputs as a constrained routing problem and validate them against a strict allowlist of internal paths. Reject any input that can be normalized into repeated browser navigation, fragment-based looping, or alternate URL forms that the server does not explicitly expect.
• Shorten the exposure window for navigation artefacts Use one-time tokens with immediate invalidation after first use, and ensure callbacks do not remain valid after repeated navigation attempts. If a token must be presented during a browser flow, make it useless after the first successful resolution so redirect retries cannot expose it again.
• Test redirect flows in real browsers, not only in server logic Validate callback and handoff flows in Chrome and other major browsers to confirm that fragments, history state, and redirect limits do not preserve sensitive values. Include error-page behavior and iframe navigation in test cases, because server-side unit tests will miss browser-only discrepancies.
• Review OAuth and magic-link designs for URL leakage Map every login, verification, and recovery flow that puts identity artefacts into a browser URL, then redesign the handoff so the browser never becomes a secret carrier. The safest pattern is to keep the URL free of credentials and move state into controlled server-side exchanges.

Key takeaways

• URL-resident session tokens and redemption links create exposure that browser behavior can amplify, even when redirect targets are restricted to paths.
• The weakness is not open redirects alone, but the combination of browser and server parsing differences with sensitive data carried in a URL.
• The control that matters most is to remove secrets from redirect-driven flows and validate browser behavior, not just server-side redirect logic.

Key terms

• Redirect Discrepancy: A redirect discrepancy is a mismatch between how the browser and the server interpret a URL during navigation. In security terms, it matters when that mismatch preserves or reveals sensitive state, such as tokens or callback parameters, long enough to be logged, replayed, or recovered.
• Session Token Exposure: Session token exposure occurs when authentication tokens or session artifacts are stored, transmitted, or logged in places they should not be. Once exposed, they can function like reusable credentials. This makes them part of identity and access risk, not only application behaviour.
• Fragment Identifier: A fragment identifier is the portion of a URL after the hash symbol that the browser uses locally and does not send to the server. Security teams care about it because browser-only processing can create a state the server never sees, which can be abused in redirect and token-handling flows.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners align identity controls with the way modern browser and service flows actually move credentials.