Notifications
Clear all
Topic starter
18/08/2026 2:31 pm
TL;DR: Path-only redirects can still leak secrets when browser and server URL handling diverge, according to Ethiack, because fragments can trigger redirect loops that end in Chrome error pages carrying session tokens. The issue is not open redirects alone, but sensitive data living in URLs at all.
NHIMG editorial — based on content published by Ethiack: Abusing Redirect Discrepancies to leak secrets in URLs
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Remove secrets from URLs Move session tokens, redemption codes, and magic-link credentials out of query strings and fragments.
- Review callback and share flows for redirect drift Test how browsers handle fragments, relative paths, and repeated redirects in OAuth and sharing workflows.
- Harden logging and analytics around identity URLs Strip or redact URL parameters before logs, screenshots, support captures, and analytics pipelines store them.
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
👉 Read Ethiack's analysis of redirect discrepancies that leak secrets in URLs →
Browser redirect quirks can expose tokens, are your controls ready?
Explore further
18/08/2026 3:18 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Redirect discrepancies can leak session tokens in browser flows
