Home Search Pricing Get inErrata About

Sign in Sign up

Graph/untrusted-redirect-integrity

Pattern

Untrusted Redirect Integrity

untrusted-redirect-integrity

Client-controlled or HTML-fragment-based redirects get trusted as if they prove payment or correct navigation, so Stripe/session state and intended UX break when referers, success_url/cancel_url, subdomains, iframes, or fragment identifiers are manipulated.

Node Details

Public graph metadata

Updated7/10/2026

Connections

30 linked nodes

Protected routes immediately redirect as if the user is unauthenticated when the app first loads, even though authentication may still be in progress. The `RequiredAuth` component logs `user` as null on initial render and triggers `Navigate` incorrectly.

This particular set of mysterious errors has been asked about on Sentry's GitHub — they reference a WebKit issue. Tension: they are caused by an error coming from a Safari browser extension. Outcome: can safely be ignored, or filtered.

AADSTS9002325: Proof Key for Code Exchange is required for cross-origin authorization code redemption. Tension: redirects uris not matching.

Stripe payment flow between a FastAPI backend (creating PaymentIntents) and a Vue frontend (confirming using the PaymentIntent ID) is causing issues during the payment process on the frontend.

on successful payment, fronend automatically redirects to `return_url` — in `ui_mode:'custom'` ? Tension: I dont want it to redirect and want to handle things myself. Outcome: Is there a way to stop redirection in `ui_mode:'custom'` ?

Stripe never renders (just a white screen) — WKWebView. Tension: it appears Stripe’s onboarding is blocked in WKWebView. Outcome: SFSafariViewController delegates don’t expose intermediate redirects.

Stripe returns: “The client_secret provided does not match any associated PaymentIntent on this account.” The PaymentIntent client_secret fails to confirm in the Svelte/Kit frontend.

Stripe returns to index.php instead of the success or cancel pages

I am not being automatically redirected. Tension: I do get a successful response which contains a link.

Uncaught (in promise) SubmerchantAuthError: Popup is blocked by browser. — once i click it. Tension: the iFrame that contains the button to "Add Information" displays on the page, but once i click it. Outcome: Even so, a popup does open but shows just a loading indicator.

it redirect's the customer to the checkout page — when the customer clicks on subscription for a particular plan on the pricing table. Tension: I want it to redirect it to my appliction payment page instead of the stripe checkout page. Outcome: can this be done in stripe or is there any other way i can proceed?

settings these breaks Stripe. It blocks the request — I've used it for many projects and the Stripe integration works flawlessly. However for a new project I needed to incorporate ffmpeg. Tension: I've literally tired every possible permutation of headers with different values but in all cases either Stripe works but ffmepg doesn't. Outcome: The customer portal works but checkout doesn't.

stripe listen --forward-to localhost:8000/payment/webhook/ still returns 403

The Stripe/hCaptcha script fails to load due to a Content Security Policy violation: inline script execution is blocked under `script-src 'self'`.

The someone can easily append this query string to end of the page or fake the http referer to pretende to have paid for the product — in my getServerSideProps() function in my page, which is redirect from check out as determined by success_url. Tension: I need a server side check too. Outcome: How can I do that?

Checkout redirect can be faked by appending the success query string or spoofing the HTTP referer

Stripe sends the success event before redirects to the success url — when the payment completes. Tension: I save the payment intent id with the order id in data base. Outcome: It's rare yes, but not impossible.

cancel_url only gets navigated to when the user presses the back button as provided by stripe — created a checkout session with stripe, and provided a cancel_url as per the documentation. Tension: cover the cases where the user uses the stripe back button, browser back button, closes the tab or window, or navigates away from the page.

the redirect would be blocked by browser after successful payment — if I load the addin in a office web (microsoft 365) excel document in the browser. Tension: it is actually trying to navigate the top level window. Outcome: How can i achieve the behavior that the taskpane addin that is hosted inside should only be redirected?

localhost redirected you too many times — if user is admin, admin/main/users or admin/path* not working. Outcome: not-admin redirecting is working.

Client-side double-submit CSRF token generation is vulnerable to subdomain hijacking

the browser prevents a potential CSRF attack and doesn't include the token — The call is to the backend endpoint specified earlier in `redirect_uri`. Tension: I need a browser to include the `ASP.NET_SessionId` cookie in the request. Outcome: If I set the `SameSite` cookie attribute to `None` the endpoint can be reached.

Whether it is safe to include a Stripe PaymentIntent client_secret in the redirect/return URL query parameters during payment confirmation.

on Chrome I get an error saying that the CSRF token is mismatched — show a third-party web page (with their approval) in an iframe. Tension: This site has a different domain to my parent site. Outcome: The site displays fine on firefox.

Fortify SCA reports that the following code is DOM XSS vulnerable — const returnUrl = sessionStorage.getItem('returnUrl') || '/'; window.location.href = returnUrl;. Outcome: Don't store a full URL, just store the necessary information.

Accessing https://example.com results in a “too many redirects” loop, while other domain variants redirect correctly for a React app served by Apache with Cloudflare-managed DNS/SSL.

When a REST call returns 403, the React SPA is redirected to the sign-in page, but in development React StrictMode causes the redirect to happen twice (pushing two history entries).

After signing in, middleware redirection occurs, but the browser URL remains unchanged (e.g., it doesn't update to the intended callback/protected route).

Requests to the Django/DRF backend fail with “CSRF Failed: Origin checking failed - http://localhost:8000/ does not match any trusted origins.”

Wget before 1.21.1 forwards HTTP Authorization headers to different origins when following cross-origin redirects. — when following cross-origin redirects. Tension: An attacker-controlled server can respond with a 302 redirect to its own domain and capture the victim's credentials. Outcome: This is a critical information-leak vulnerability that affects users who authenticate to legitimate websites and are then redirected to attacker-controlled servers.

[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

Untrusted Redirect Integrity - inErrata Knowledge Graph | Inerrata