How Firefox Handles Cookies Without a SameSite Attribute

This article provides an overview of how the Mozilla Firefox web browser processes HTTP cookies that do not explicitly declare a SameSite attribute. It explains the browser's transition from permissive default behaviors to stricter security standards, details the "SameSite=Lax by default" policy, and outlines how these rules interact with Firefox's built-in Total Cookie Protection to prevent cross-site attacks and unauthorized tracking.

The Historical Behavior: SameSite=None

Historically, when a web server set a cookie without specifying a SameSite attribute, Firefox treated it as SameSite=None. Under this behavior, the browser would send the cookie with both first-party requests (on the same website) and third-party requests (such as embedded iframes, images, or scripts on external websites). While this ensured maximum compatibility across the web, it left users vulnerable to Cross-Site Request Forgery (CSRF) attacks and pervasive cross-site tracking.

The Modern Standard: SameSite=Lax by Default

To improve security and align with modern web standards, Firefox updated its cookie handling policy to treat cookies without a SameSite attribute as SameSite=Lax by default.

When a cookie defaults to SameSite=Lax in Firefox, the browser enforces the following rules:

  • First-Party Contexts: The cookie is sent normally when the user is browsing the website that originally created the cookie.
  • Cross-Site Top-Level Navigations: The cookie is sent when a user navigates to the cookie's origin site from an external site, such as by clicking a standard link (<a> tag). This ensures users stay logged into websites when following links from emails or search engines.
  • Cross-Site Subrequests: The cookie is withheld from third-party requests triggered in the background, such as <img> tags, <iframe> elements, or fetch() requests originating from a different domain.

The Two-Minute "Lax + POST" Grace Period

Enforcing SameSite=Lax by default initially broke several older websites, particularly those relying on cross-site POST requests for Single Sign-On (SSO) authentication and payment gateways.

To maintain web compatibility, Firefox implements a temporary exception known as "Lax + POST." If a cookie is set without a SameSite attribute, Firefox allows it to be sent on top-level, cross-site POST requests for the first two minutes of the cookie's life. Once two minutes have passed, the cookie strictly adheres to standard SameSite=Lax rules, and cross-site POST requests will no longer include it.

In addition to SameSite rules, Firefox enforces a privacy feature called Total Cookie Protection (also known as dynamic First-Party Isolation).

Even if a cookie without a SameSite attribute is somehow permitted in a cross-site context, or if the SameSite=Lax default is disabled by the user, Total Cookie Protection isolates the cookie. Firefox creates a separate "cookie jar" for every website a user visits. If a third-party domain attempts to use a cookie on two different websites, Firefox restricts that cookie to the specific site where it was created, rendering cross-site tracking ineffective.

Managing the Behavior in Firefox

Developers and advanced users can view or modify how Firefox handles unspecified SameSite cookies using the browser's advanced configuration page. By typing about:config into the Firefox address bar, users can search for the following preferences:

  • network.cookie.sameSite.laxByDefault: When set to true, Firefox applies SameSite=Lax to cookies without an explicit attribute.
  • network.cookie.sameSite.noneRequiresSecure: When set to true, any cookie that explicitly opts out of the default behavior by declaring SameSite=None must also include the Secure attribute (requiring HTTPS), otherwise Firefox will reject the cookie entirely.