SameSite Cookies

What SameSite Cookies Do

SameSite is a cookie attribute, not a separate cookie type. It tells the browser when to include a cookie on cross-site requests, so the server can limit where session cookies travel and reduce ambient cross-site exposure.

In practice, SameSite changes browser behaviour at the boundary between a user’s current site and another site that tries to trigger a request. That makes it one of the most important cookie attributes for controlling whether authentication state is sent during embedded content, navigations, and form submissions.

SameSite Modes and Their Security Meaning

The three modes, Strict, Lax, and None, express different trust assumptions. Strict is the most restrictive, Lax permits some top-level navigation scenarios, and None allows cross-site inclusion when the cookie is marked for it and other cookie requirements are met.

Those differences matter because the browser is enforcing the policy before the request reaches the application. A site that chooses the wrong mode may unintentionally send a session cookie in a context it did not intend, while an overly strict setting can break legitimate login flows, embedded functionality, or federated journeys.

How SameSite Supports Browser-Side Request Control

SameSite is a browser-side control over credential forwarding, so it works best when applications also rely on server-side request validation. It reduces one common route for unsolicited state-changing requests, but it does not replace CSRF tokens, origin checks, or careful session handling.

It is also important to remember that SameSite is evaluated by the browser and by the shape of the request. Edge cases can arise around redirects, embedded content, browser differences, and changing standards behaviour, so teams should test the exact flows their application depends on rather than assuming every request pattern will behave identically.

Where SameSite Fits in Modern Web Security

SameSite is now part of the baseline cookie security conversation alongside Secure, HttpOnly, prefixes, and session design. It is especially useful for session cookies, because those cookies carry the authority of the logged-in user and are the most sensitive to cross-site leakage or unintended inclusion.

For teams that want a deeper reference point, the Cookie Security Guide covers safe use of cookie attributes, while the CSRF Prevention Guide shows how SameSite fits into a broader anti-CSRF strategy. The Security Headers Guide places it alongside other browser-enforced controls that help harden web sessions.

Risk and Threat Considerations

SameSite reduces one class of cross-site request abuse, but it is easy to misconfigure or over-trust. If a sensitive cookie is left permissive where a restrictive setting was intended, an attacker can sometimes use a cross-site request path to trigger actions with the victim’s authenticated context.

Failure mechanism: The browser sends a session cookie on a cross-site request because the cookie policy, request type, or application flow allows it, and the server treats that request as fully authenticated.

Impact: The result can be unauthorized state change, CSRF-style account action, session misuse, or broader trust boundary failure for browser-mediated workflows.

Practitioner Guidance

Why practitioners should care: SameSite is a session-control decision, not a cosmetic header choice. Treat it as part of the application’s authentication and request-authorisation design, especially for login state, sensitive transactions, and any feature that accepts browser-originated requests.

What to watch for: Verify that each cookie’s setting matches its real usage, then test the full set of user journeys, including redirects, embedded flows, and third-party integrations. Where business requirements demand cross-site inclusion, make sure the broader anti-CSRF design still provides compensating protection.

Related resources from NHI Mgmt Group

• What do teams get wrong about SameSite cookies and CSRF risk?
• How should teams harden single-page app authentication when third-party cookies and SameSite changes break browser-side OAuth flows?
• Should teams rely on SameSite cookies or CORS instead of CSRF tokens?
• How should teams handle cookies that do not explicitly set Secure, HttpOnly, and SameSite?