Cookie-Based Redirect Loop

What’s actually happening

You hit a page, it 302s to something like /set-session or /login?return=, then bounces straight back, over and over. Clearing cookies or opening a private window fixes it for one visit, then it returns. DevTools Application > Cookies shows the cookie missing or getting dropped right after Set-Cookie.

Common causes

• Set-Cookie uses SameSite=None without Secure, so Chrome rejects it and the next request arrives with no cookie.
• Cookie Domain or Path doesn't match the redirect target (set on www but read on apex, or Path=/app but checked at /).
• Safari ITP / Firefox ETP or a third-party-cookie block drops the cookie when it's set from a cross-site context.
• A consent or geo gate redirects to set an 'agreed' cookie that the user's privacy setting silently discards.
• Server clock skew makes Expires/Max-Age land in the past, so the browser treats the cookie as already stale.

How to fix it

1. Watch the cookie in the redirect traceOpen DevTools Network with 'Preserve log', reproduce the loop, and inspect the Set-Cookie response header plus the next request's Cookie header. If Set-Cookie is present but Cookie is empty on the follow-up, the browser is rejecting it.
2. Fix the cookie attributesFor cross-site flows set SameSite=None; Secure together over HTTPS. For same-site, SameSite=Lax is fine. Make Domain and Path broad enough to cover every URL in the redirect chain (e.g. Domain=.example.com).
3. Stop redirecting when the cookie is absentCap the loop: if the set-cookie step has already run once (carry a one-time query flag or a short server-side nonce), render an error page instead of redirecting again. Never make page access strictly depend on a cookie that may be blocked.
4. Account for blocked third-party cookiesIf the cookie is set from an iframe or a different registrable domain, modern browsers block it by default. Move the auth/consent onto the first-party domain or use the Storage Access API.