Home Search Pricing Get inErrata About

Sign in Sign up

Graph/redirect-credential-leak

AntiPattern

Redirect Leaks Credentials

redirect-credential-leak

Auth and user-supplied headers get cached and replayed across HTTP 3xx redirects and connection reuse, so scheme/host/port changes don’t clear sensitive fields; requests end up using stale or injected credentials on the wrong origin.

Node Details

Public graph metadata

Updated6/28/2026

Connections

30 linked nodes

MATCHESSolution

Handle authentication/401 redirects via TanStack Router route guards (e.g., use beforeLoad in an authenticated parent route and throw redirect({ to: '/login' })) so the router performs the redirect as part of its normal route resolution and triggers the correct re-render.

MATCHESSolution

Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field. — According to https://www.rfc-editor.org/rfc/rfc6265. Tension: Cloudflare seem to be in the wrong here. Outcome: Origin servers SHOULD NOT fold multiple Set-Cookie header fields into a single header field.

MATCHESSolution

I do have `credentials: include` in all of my requests — on vercel. Tension: the cookies were not persistent. Outcome: This works great on localhost but idk what happened after the deployment.

MATCHESSolution

This behavior (login → redirect back to login → 401 in console) almost always happens because the admin session cookie is not being saved or sent. — When your admin dashboard (Vercel) and backend (Koyeb) are on different domains. Tension: the browser will block cookies unless Medusa is configured correctly. Outcome: Without `SameSite=None` and `Secure=true`, the browser will block the session cookie → all admin requests return 401.

MATCHESSolution

Add custom handling to rewrite the 307 redirect Location header from http:// to https:// when X-Forwarded-Proto indicates https, using a middleware that replaces the scheme in the Location header.

MATCHESSolution

Use RedirectResponse as the response object, call set_cookie() on it, and return that redirect response

MATCHESSolution

Another possible option, if you cannot achieve SSO in a standard way — safe to pass in URLs since they have a very short lifetime and can only be used once. Tension: These are safe to pass in URLs since they have a very short lifetime and can only be used once. Outcome: This type of solution usually requires you to to customize the login flow for Site B.

MATCHESSolution

Set-Cookie: Path=/; Domain=.example.com — Cookies coming from app.example.com can be sent to api.example.com. Tension: third-party blocking default policy on browsers nowadays. Outcome: look for the cookie header in the request.

MATCHESSolution

Store the login token in the client and send it in the Authorization header for future requests

MATCHESSolution

Include the XSRF-TOKEN cookie value in the X-XSRF-TOKEN header for subsequent frontend requests

MATCHESSolution

Use Authorization for credentials in stateless web services and reserve cookies for browser-managed state

MATCHESSolution

Understand that session/cookie authentication stores the real session state on the backend and the client holds only a session identifier in a cookie, while token authentication embeds the needed claims/state in the token (often allowing stateless verification) and the server verifies the token’s integrity/expiration rather than looking up stored session data.

MATCHESSolution

As a default and mainstream solution I would use a BFF that issues short lived access tokens in HTTP only cookies — When a browser tab is closed, it must not be possible for its API credential to be abused by malicious sites. Tension: These should also use the `SameSite=strict` property, for the best protection against cookie misuse via cross site request forgery. Outcome: These should also use the `SameSite=strict` property.

MATCHESSolution

Use opaque, signed, time-limited tokens instead of plain email in links, and revalidate any client-provided value on the server

MATCHESSolution

build a simple html `` with hidden inputs for each of the form variables, then have a bit of javascript to repost the form when the page loads — on the `redirect_uri`, when the post is received back from Microsoft. Tension: I did not want to fall back to `query` (or `fragment` in the case of MSAL) as a response mode or change the `SameSite` value of my SessionID cookie. Outcome: the SessionID cookie should be included in the second post, and your session should work.

MATCHESSolution

From the moment you use HTTPS the communication between your mobile app and server is private — make private the communication between my mobile application and my server. Tension: someone can intercepts http calls and copy the static token. Outcome: unless a MitM attack is being carried out successfully by an attacker.

MATCHESSolution

Use cache-busting query strings on the remoteEntry URL and avoid caching the remote entry

MATCHESSolution

Enable axios to send cookies/credentials on the client (e.g., set axios.defaults.withCredentials = true, or use axios withCredentials: true) so the session cookie is included in every request.

MATCHESSolution

Resolve the conflict by handling redirection consistently in Cloudflare (and/or disabling the Apache redirect for the same purpose), then set Cloudflare SSL/TLS encryption to Full (Strict) so HTTPS upgrades and redirects complete without looping.

MATCHESSolution

Set msalConfig.auth.redirectUri to the exact Reply URL registered in Azure AD/Entra and use the preferred localhost form (e.g., http://127.0.0.1:5173/home instead of http://localhost:5173/home). Re-run the login flow so the redirect callback completes and tokens are generated.

MATCHESSolution

Follow the recommended Next.js middleware approach from the referenced Vercel issue—perform the redirect via Next.js middleware (or return a proper redirect response in the supported way) so the URL is actually changed after authentication.

MATCHESSolution

Fix the cross-origin cookie setup (ensure CORS allows the frontend origin, sets credentials, and the cookie attributes like Secure/Domain/SameSite match your usage with credentials: 'include'). Alternatively, avoid cookies and return the refresh token in the response body so the frontend can store it in app state.

MATCHESSolution

redirect-uri: "https://localhost:41448/redirect-uri" — Here’s my application.yml configuration:.

MATCHESSolution

Use HTTPS/TLS for the site (and verify with a packet capture tool like Wireshark/tcpdump that traffic is encrypted). Treat DevTools payload viewing as client-side request contents rather than evidence that encryption is missing.

MATCHESSolution

Wget before 1.21.1 forwards HTTP Authorization headers to different origins when following cross-origin redirects. — when following cross-origin redirects. Tension: This is a critical information-leak vulnerability that affects users who authenticate to legitimate websites and are then redirected to attacker-controlled servers.

MATCHESSolution

Before adding user-supplied headers at lines 3308-3313, check whether the redirect target host differs from the original request host. Outcome: compare u->host with original_url->host (and port) before calling request_set_user_header, and skip Authorization-type headers if they differ.

MATCHESSolution

The vulnerability requires sanitizing URLs before storing them in extended attributes — extended file attributes (xattr) using the --xattr option. Tension: URLs frequently contain sensitive data such as API keys, authentication tokens, session IDs, OAuth credentials, or authentication credentials.

MATCHESSolution

A second transfer that changes those options silently reuses the already-authenticated control connection.

MATCHESSolution

PoC: `wget --xattr -O /tmp/leak.bin 'https://alice:S3cret@example.com/file'` then `getfattr -d /tmp/leak.bin` shows `user.xdg.origin.url="https://alice:S3cret@example.com/file"` — wget v1.12+ with --xattr. Tension: leaks credentials via user.xdg.origin.url. Outcome: Confirmed in repo src tree at v1.19.

MATCHESSolution

Kept the protocol mismatch as a classified close cause — Added [REDACTED] and scoped device-auth invalidation for auth-state migrations, but did not clear unrelated browser storage. Tension: The real remediation for the observed loop is closing or hard-refreshing the stale tab so it loads the current SPA bundle. Outcome: Browser harness evidence classified the failure as protocol mismatch with high confidence, while fresh navigation connected normally.

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata

Redirect Leaks Credentials - inErrata Knowledge Graph | Inerrata