Cookies and the Cross-Site Problem

Cookies let websites remember users — their preferences, session state, or shopping cart contents. But because cookies are attached to requests automatically, they also create a decision point: should a cookie be sent when the request comes from another site? Left unmanaged, cookies can be leveraged for cross-site request forgery (CSRF) or unintended data sharing.

The SameSite attribute addresses this by telling the browser when a cookie may be included in cross-site requests. It accepts one of three values: Strict, Lax, or None.

Strict: Origin-Only Delivery

With SameSite=Strict, the browser sends the cookie only when the request originates from the same site. No cross-site request — whether a link click, an embedded image, or a form POST — will carry the cookie.

This is the most restrictive option and suits high-security contexts such as online banking, where any cross-site usage should be blocked to protect data confidentiality.

Lax: A Middle Ground

SameSite=Lax relaxes the rules for one specific case: top-level navigations. If a user clicks a link from another site to yours, the cookie is sent. But for cross-site subresource requests — images, stylesheets, scripts — the cookie is withheld.

This configuration is well-suited for sites that embed content elsewhere but still want to preserve user sessions when visitors arrive via external links. Notably, if the SameSite attribute is omitted entirely, modern browsers default to Lax behavior.

None: Full Cross-Site Access

SameSite=None allows the cookie to accompany every request, including cross-site ones. However, this setting comes with a mandatory condition: the cookie must also carry the Secure attribute, restricting it to HTTPS connections. Attempting to set SameSite=None without Secure on an HTTPS site will trigger a browser console warning, and the cookie will not work as intended.

This option is necessary for scenarios like cross-site tracking by advertising platforms, single sign-on systems that authenticate across multiple domains, or features explicitly designed to be invoked from external websites.

Choosing a Setting

The right choice depends on what the cookie is for:

  • Maximum security: use Strict. The cookie never leaves its origin, reducing CSRF risk and accidental data leaks.
  • Balanced usability and safety: use Lax. It keeps sessions intact for link-based navigation while still blocking most cross-site request types.
  • Cross-site data sharing: use None, paired with Secure to enforce HTTPS transport.

Understanding these three modes gives developers granular control over cookie delivery, allowing them to lock down sensitive data or enable cross-site workflows without weakening session security.