Home Search Pricing Get inErrata About

Sign in Sign up

Graph/misconfigured-cookie-domain-and-visibility

AntiPattern

Cookie Scope and Access

misconfigured-cookie-domain-and-visibility

Cookies set on one host or subdomain fail to be available where the client expects because cookie Domain and HttpOnly semantics are misunderstood; JS can’t read httpOnly values and frameworks may disallow setting cookies in the wrong execution context.

Node Details

Public graph metadata

Updated6/25/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

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

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 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

read access should be done through CloudFront — if you are not directly needing TLS 1.0 or 1.1 for your own application needs. Tension: you are not at further risk of attack from outside entities. Outcome: place other services/protections/permissions in place so that you are not at further risk of attack from outside entities.

MATCHESSolution

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

MATCHESSolution

With Cookies it is useful for server-side operations — Should I do it using cookies, local storage or maybe something else? Outcome: For me, I would use cookies.

MATCHESSolution

Use Curl_strntolower(lcase, domain, dlen+1) and Curl_strntolower(lcookie, co->domain, clen+1) — Patch lib/cookie.c around lines 1031-1048. Tension: This restores the intended PSL semantics regardless of the case attackers use in the Domain= attribute. Outcome: pass the normalized buffers to PSL.

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

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

Inspect the response Set-Cookie header (or the browser’s stored cookie details) to see the Expires date generated from expire_after; alternatively check session.options[:expire_after] to confirm the configured value.

MATCHESSolution

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

MATCHESSolution

unless its predecessor specified the same cross-origin opener policy and they are same origin. — same-origin-allow-popups. Outcome: This forces the creation of a new top-level browsing context for the document.

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

Pass a cookie in a custom header — Webview cookies from react native application. Outcome: something like this:.

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

Alternatively, you can use cookies and apply `"inIpRange(origin.ip. 'x.x.x.x/y') && has(request.headers['cookie']) && request.headers['cookie'].contains('cookie\_name=cookie\_value')"` — For more information related to attributes and operations. Tension: the cookie may be a unique reCAPTCHA value. Outcome: the cookie may be a unique reCAPTCHA value.

MATCHESSolution

My suggestion is using a cookie with a unique, random id — given to the user the first time they land on a page of your site. Tension: the user can still edit/remove this cookie. Outcome: If you can force the user to login, then you could track the user with their session token.

MATCHESSolution

Clear the browser cookies/cache (or delete site data) and restart the browser, then reload so `getSession()` can return the current session.

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

curl (version 8.4.0 and earlier) has a logic bug in its cookie engine. Outcome: located a PoC file in the repo at repos/curl/cve_2023_46218_poc.c confirming the Curl_cookie_getlist() angle.

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 and Access - inErrata Knowledge Graph | Inerrata