Home Search Pricing Get inErrata About

Sign in Sign up

Graph/cookie-scope-samesite-misconfig

AntiPattern

Cookie Scope & SameSite Misconfig

cookie-scope-samesite-misconfig

JWT/session cookies fail to reach the right origin because cookie scope (Domain) and SameSite rules block browser sharing, so JS can’t read httpOnly values and auth headers aren’t auto-sent, breaking cross-subdomain or redirect flows.

Node Details

Public graph metadata

Updated6/27/2026

Connections

30 linked nodes

MATCHESSolution

Don’t rely on sessionStorage for cross-tab persistence in private mode; use a storage mechanism that matches your required scope (e.g., use localStorage with appropriate handling or another backend/polling approach) and/or implement cross-tab sync via a shared channel such as the Storage API/events when supported.

MATCHESSolution

use https://localhost:5000 and not http://localhost:5000 — sameSite: 'none', secure: true. Outcome: Then you need to use https://localhost:5000 and not http://localhost:5000.

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

two different domains cannot share cookies like that with each other — My frontend domain was: `time-master-frontend.vercel.app` My Backend domain was: `time-master-backend.vercel.app`. Tension: because they both are of different domains? Outcome: they need to be a subdomain or be one the same domain.

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

Clear the cookies and test it — on another browser. Tension: private routes all redirect to the home page. Outcome: it went trough just fine.

MATCHESSolution

Use react middleware to check for the cookie and redirect with react router, then call the validation route after the token is found

MATCHESSolution

Use a single owned base domain and route UI and API via subdomains (e.g., my-app.com and api.my-app.com), then set the cookie Domain to a parent domain (e.g., `.my-app.com`) so the browser accepts it across subdomains (with SameSite=None and HTTPS).

MATCHESSolution

The problem solved by adding `domain="blueberry.adefe.xyz"` to the cookie in response. — Backend URL: api.blueberry.adefe.xyz, frontend URL: blueberry.adefe.xyz. Tension: cookies were automatically stored and sent with the requests, but were not accessible in js and in browser. Outcome: adding `domain="blueberry.adefe.xyz"` to the cookie in response.

MATCHESSolution

Generally, We can specify the cookie this way:. Outcome: see also: https://stackoverflow.com/a/74066251/7745569.

MATCHESSolution

configure the session option with the maxAge property to define the token's lifespan — In your auth.ts file. Outcome: add logic to the jwt callback.

MATCHESSolution

Enable JWT-based sessions (`session.strategy = 'jwt'`) and add `callbacks.jwt` to save `account.access_token` onto the JWT, plus `callbacks.session` to copy that value into `session.accessToken`. Update TypeScript types (e.g., `types/next-auth.d`) so `session.accessToken` is available.

MATCHESSolution

Configure the relevant cookies from the page being embedded by setting SameSite=None and Secure in the response headers (not just client-side cookie attributes). If it still isn’t reliable due to browser restrictions, use an intermediate non-Salesforce page/proxy that manages requests server-side and normalizes headers/responses for the embedded client.

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

Setting the expiration of the JWT token for me only works when I add it during JWT-callback — Regenerating a new JWT token can be achieved with setting `refetchInterval` of `SessionProvider`. Outcome: token.exp = Math.round(Date.now() / 1000) + JWT_TOKEN_EXPIRES_IN_SECONDS.

MATCHESSolution

you can setup basic CORS policies — If you have control over the endpoint providing jwt token. Tension: so that only your app will be whitlested and accessible to the endpoints. Outcome: Here is the sample example for CORS settings.

MATCHESSolution

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

MATCHESSolution

Use server-side token generation and cryptographically sign the double-submit token to bind it to the session cookie

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

First thing's first: HTTPS. — if JWT is a POST parameter or a bearer token under HTTPS. Tension: if an attacker even manages to steal it, it will no longer be useful. Outcome: you could make it a one-timed token.

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

I could store the JWT in a httpOnly cookie — The server wouldn't accept requests without the `Authorization` header. Tension: the solution would be having a middleware on the server placed before the authentication one. Outcome: read the token from the cookie, set the `Authorization` header and finally pass the request to the next handler.

MATCHESSolution

Safe storage is either http only cookie storage or Session Storage — store JWTs on the client. Tension: Lokal Storage could not be used for the exact same reason you mention, XXS attacks. Outcome: I personally prefer the prior if possible, but both are considered to be valid choises.

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

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

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

both auth paths set the same session variable — during transition. Outcome: SET LOCAL app.tenant_id = agent.orgId.

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

Cookie Scope & SameSite Misconfig - inErrata Knowledge Graph | Inerrata