The SameSite cookie warning — variations like "Cookie will be rejected because it is foreign and does not have the SameSite=None attribute" — means a browser is enforcing modern cross-site cookie restrictions, and a cookie your application sets doesn't explicitly declare a SameSite value that matches how it's actually being used.
This warning means a cookie is being sent or received across origins (a cross-site request, an embedded iframe, a third-party redirect flow) without the specific SameSite attribute configuration that modern browsers now require for that usage — since Chrome's SameSite=Lax default change in 2020, cookies without an explicit SameSite value are treated as Lax by default, which blocks many cross-site scenarios unless explicitly configured otherwise.
Why This Error Happens
Browsers default unlabeled cookies to SameSite=Lax, restricting them from being sent on most cross-site requests as a baseline CSRF/tracking protection measure. A cookie genuinely needing cross-site behavior (embedded third-party widgets, cross-domain authentication flows, payment provider iframes) must explicitly set SameSite=None, and doing so additionally requires the Secure attribute (HTTPS-only) — the warning fires when a cookie's actual usage pattern doesn't match its declared (or default) SameSite configuration.
Reproducing the Error
A cookie set without explicit SameSite, being used cross-site (e.g., in an iframe embedded on another domain):
res.cookie("session", token, {
httpOnly: true,
secure: true,
// No sameSite specified — defaults to Lax, which blocks this cookie
// from being sent in a cross-site iframe context
});
Cookie "session" will be rejected because it is foreign and does not have
the "SameSite=None" attribute, or because it is missing the "Secure" attribute.
Core Concepts Behind This Error
SameSite=Strict sends the cookie only for same-site requests, never cross-site, even when a user navigates via a link from an external site — appropriate for highly sensitive cookies (like a banking session) but too restrictive for normal login flows involving external redirects.
SameSite=Lax (the default) allows the cookie for top-level navigations (clicking a link, typing a URL) but blocks it for cross-site subresource requests (embedded images, iframes, background fetch/XHR from another origin) — this default strikes a reasonable balance for most cookies and is why simply not specifying SameSite doesn't automatically break normal login flows.
SameSite=None explicitly opts a cookie into being sent in all cross-site contexts, but mandatorily requires the Secure attribute alongside it — browsers reject SameSite=None cookies missing Secure, since sending a cookie cross-site over an insecure connection would be a meaningful security risk.
This warning specifically targets legitimate cross-site cookie use cases (embedded third-party content, cross-domain SSO, payment iframes) — for the large majority of application cookies that are only ever used same-site, the default Lax behavior is correct and this warning shouldn't appear at all, making its appearance a useful signal that a cookie's actual usage doesn't match expectations.
Fixing SameSite Cookie Warnings
Fix 1: For cookies genuinely needing cross-site behavior, explicitly set SameSite=None with Secure:
res.cookie("widget_session", token, {
httpOnly: true,
secure: true, // mandatory when sameSite is None
sameSite: "none",
});
Fix 2: For normal application cookies not needing cross-site behavior, explicitly set SameSite=Lax (or leave it as the default) rather than leaving it ambiguous, making the intent clear in code:
res.cookie("session", token, {
httpOnly: true,
secure: true,
sameSite: "lax", // explicit, matches actual intended usage
});
Fix 3: For highly sensitive cookies where cross-site access should never happen even via top-level navigation, use SameSite=Strict:
res.cookie("admin_session", token, {
httpOnly: true,
secure: true,
sameSite: "strict",
});
Fix 4: If a third-party cookie warning originates from an embedded widget or script you don't control, check whether that provider has updated their cookie configuration — this isn't something fixable from your own application code when the cookie belongs to an external service.
Does SameSite=None Alone Make a Cookie Insecure?
No — SameSite=None combined with the mandatory Secure attribute (HTTPS-only transmission) and, ideally, HttpOnly (inaccessible to JavaScript) is a legitimate, secure configuration for cookies that genuinely need cross-site behavior; it's not inherently less secure than Lax, just differently scoped. The security consideration is ensuring SameSite=None is used deliberately for cookies that actually need cross-site behavior, not applied broadly as a way to silence the warning without considering whether that cookie should be cross-site accessible at all.
Preventing This Error in Production
Set SameSite explicitly on every cookie your application creates, matching its actual intended usage pattern (Strict for highly sensitive same-site-only cookies, Lax for normal application cookies, None with Secure specifically for legitimate cross-site use cases) rather than relying on browser defaults implicitly. Audit third-party embedded widgets and scripts periodically for cookie warnings originating from their code, since browser cookie policy changes can surface issues in dependencies you don't directly control.
If you see this warning, first determine whether the cookie genuinely needs cross-site behavior — if it doesn't, explicitly setting SameSite=Lax (matching the default but making intent clear) is usually sufficient; if it does, SameSite=None with Secure is the correct, deliberate fix.