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.
Editorial analysis by NHI Mgmt Group, based on content published by Ethiack: “Abusing Redirect Discrepancies to leak secrets in URLs”.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
Bottom line: URL-resident session tokens and redemption links create exposure that browser behavior can amplify, even when redirect targets are restricted to paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:18 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Redirect discrepancies can leak session tokens in browser flows