The definition of "same-site" is expanding to include the URL scheme. Under Schemeful Same-Site, links between the HTTP and HTTPS versions of a site are now treated as cross-site requests. If your site is fully on HTTPS, nothing changes. If not, the behavior of SameSite cookies in several common scenarios will be affected.

Motivation: Closing the CSRF gap

The shift to SameSite=Lax as the default for cookies was meant to mitigate Cross-Site Request Forgery (CSRF) attacks. However, insecure HTTP traffic gives network attackers an avenue to tamper with cookies that could later be used on the secure HTTPS version of the site. By treating different schemes as different sites, browsers add another defense layer against such interference.

Testing the change

You can enable the new behavior early in both Chrome and Firefox:

  • Chrome 86 and later: enable about://flags/#schemeful-same-site. Progress is tracked on the Chrome Status page.
  • Firefox 79 and later: set network.cookie.sameSite.schemeful to true via about:config. Track progress via the Bugzilla issue.

Cross-scheme scenarios that will change

Navigating between cross-scheme versions of a site—for instance, from http://site.example to https://site.example—was previously treated as a same-site navigation, allowing SameSite=Strict cookies to be sent. Under Schemeful Same-Site, this is now a cross-site navigation, so SameSite=Strict cookies will be blocked.

A cross-scheme navigation triggered by following a link on the insecure HTTP version of a site to the secure HTTPS version. SameSite=Strict cookies blocked, SameSite=Lax and SameSite=None; Secure cookies are allowed.
Cross-scheme navigation from HTTP to HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Blocked ⛔ Blocked
SameSite=Lax ✓ Allowed ✓ Allowed
SameSite=None;Secure ✓ Allowed ⛔ Blocked

Loading subresources

Subresources include images, iframes, and network requests made with XHR or Fetch. Loading a cross-scheme subresource on a page previously allowed SameSite=Strict or SameSite=Lax cookies to be sent or set. Those cookies are now blocked, just as with any other third-party or cross-site subresource. Even if the browser permits loading insecure resources on a secure page, all cookies on those requests will be blocked, since third-party or cross-site cookies require the Secure attribute.

Any adjustments here are intended as a temporary fix while you move to full HTTPS.

A cross-scheme subresource resulting from a resource from the secure HTTPS version of the site being included on the insecure HTTP version. SameSite=Strict and SameSite=Lax cookies blocked, and SameSite=None; Secure cookies are allowed.
An HTTP page including a cross-scheme subresource via HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Blocked ⛔ Blocked
SameSite=Lax ⛔ Blocked ⛔ Blocked
SameSite=None;Secure ✓ Allowed ⛔ Blocked

POSTing a form

Posting between cross-scheme versions of a site previously allowed cookies set with SameSite=Lax or SameSite=Strict to be sent. This is now a cross-site POST, so only SameSite=None cookies can be sent. This often appears on sites that default to the insecure version but upgrade users to secure on form submission—like sign-in or checkout. As with subresources, if the request goes from a secure context (HTTPS) to an insecure one (HTTP), all cookies are blocked because cross-site cookies require Secure.

A cross-scheme form submission resulting from a form on the insecure HTTP version of the site being submitted to the secure HTTPS version. SameSite=Strict and SameSite=Lax cookies blocked, and SameSite=None; Secure cookies are allowed.
Cross-scheme form submission from HTTP to HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Blocked ⛔ Blocked
SameSite=Lax ⛔ Blocked ⛔ Blocked
SameSite=None;Secure ✓ Allowed ⛔ Blocked

Developer tooling and diagnostics

Chrome and Firefox both expose messaging to help identify affected cookies.

From Chrome 86, the Issue tab in DevTools will flag Schemeful Same-Site problems. You may see navigation-related messages such as "Migrate entirely to HTTPS to continue having cookies sent on same-site requests" (cookie will be blocked in a future Chrome version) or "Migrate entirely to HTTPS to have cookies sent on same-site requests" (cookie has been blocked).

Subresource issues produce similar warnings: "Migrate entirely to HTTPS to continue having cookies sent to same-site subresources" or "…to continue allowing cookies to be set by same-site subresources" for upcoming blocking; "Migrate entirely to HTTPS to have cookies sent to same-site subresources" or "…to allow cookies to be set by same-site subresources" for already-blocked cases. The latter message can also surface when POSTing a form.

Further detail is available in Testing and Debugging Tips for Schemeful Same-Site.

From Firefox 79, with network.cookie.sameSite.schemeful set to true, the console will display messages like "Cookie cookie_name will be soon treated as cross-site cookie against http://site.example/ because the scheme does not match," or the version indicating the cookie has been treated as cross-site.

When HTTPS is complete but warnings persist

If your site is fully on HTTPS yet DevTools still shows issues, some links or subresources may still point to insecure URLs. Using HTTP Strict-Transport-Security (HSTS) with the includeSubDomain directive forces the browser to upgrade any accidental insecure requests to their secure equivalents.

If full HTTPS is not immediately possible

Upgrading entirely to HTTPS is strongly recommended. If you can't do it yourself, check with your hosting provider about offering it. For self-hosted sites, Let's Encrypt provides tools to install and configure a certificate. A CDN or other proxy that terminates HTTPS is another option.

If none of those work, you can temporarily relax SameSite protection on affected cookies:

  • If only SameSite=Strict cookies are blocked, lower the setting to Lax.
  • If both Strict and Lax cookies are blocked and the cookie is sent to or set from a secure URL, use None.

This workaround fails when the URL is insecure, because SameSite=None requires the Secure attribute, so those cookies can't be sent or set over plain HTTP. Also keep in mind that this is only a stopgap—third-party cookies are being phased out entirely, so eventually SameSite=None won't help either.

Cookies without a declared SameSite value

Cookies without an explicit SameSite attribute behave as SameSite=Lax. Under Schemeful Same-Site, the same cross-scheme rules apply to these cookies. The temporary exception for unsafe methods remains in effect; see the Lax + POST mitigation in the Chromium SameSite FAQ.

WebSocket connections

WebSocket connections are still same-site when they match the security level of the page. A wss:// connection from an https:// page is same-site, as is a ws:// connection from an http:// page. A wss:// connection from http:// or a ws:// connection from https:// is cross-site.