The definition of "same-site" is evolving to include the URL scheme, so links between HTTP and HTTPS versions of a site now count as cross-site requests. Upgrade to HTTPS by default to avoid issues where possible or read on for details of what SameSite attribute values are needed.
This article is part of a series on the SameSite
cookie attribute changes:
Schemeful Same-Site modifies the definition of a (web)site from just the registrable domain to the scheme + registrable domain. You can find more details and examples in Understanding "same-site" and "same-origin".
Key Term: This means that the insecure HTTP version of a site, for example, http://website.example, and the secure HTTPS version of that site, https://website.example, are now considered cross-site to each other.
The good news is: if your website is already fully upgraded to HTTPS then you don't need to worry about anything. Nothing will change for you.
If you haven't fully upgraded your website yet then this should be the priority. However, if there are cases where your site visitors will go between HTTP and HTTPS then some of those common scenarios and the associated SameSite
cookie behavior are outlined below.
Warning: The long-term plan is to phase out support for third-party cookies entirely, replacing them with privacy preserving alternatives. Setting SameSite=None; Secure
on a cookie to allow it to be sent across schemes should only be considered a temporary solution in the migration towards full HTTPS.
You can enable these changes for testing in both Chrome and Firefox.
chrome://flags/#schemeful-same-site
. Track progress on the Chrome Status page.network.cookie.sameSite.schemeful
to true
via about:config
. Track progress via the Bugzilla issue.One of the main reasons for the change to SameSite=Lax
as the default for cookies was to protect against Cross-Site Request Forgery (CSRF). However, insecure HTTP traffic still presents an opportunity for network attackers to tamper with cookies that will then be used on the secure HTTPS version of the site. Creating this additional cross-site boundary between schemes provides further defense against these attacks.
Key Term: In the examples below where the URLs all have the same registrable domain, e.g. site.example, but different schemes, for example, http://site.example vs. https://site.example, they are referred to as cross-scheme to each other.
Navigating between cross-scheme versions of a website (for example, linking from http://site.example to https://site.example) would previously allow SameSite=Strict
cookies to be sent. This is now treated as a cross-site navigation which means SameSite=Strict
cookies will be blocked.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict | ⛔ Blocked | ⛔ Blocked |
SameSite=Lax | ✓ Allowed | ✓ Allowed |
SameSite=None;Secure | ✓ Allowed | ⛔ Blocked |
Warning: All major browsers block active mixed content such as scripts or iframes. Additionally, browsers including Chrome and Firefox are working toward upgrading or blocking passive mixed content.
Any changes you make here should only be considered a temporary fix while you work to upgrade to full HTTPS.
Examples of subresources include images, iframes, and network requests made with XHR or Fetch.
Loading a cross-scheme subresource on a page would previously allow SameSite=Strict
or SameSite=Lax
cookies to be sent or set. Now this is treated the same way as any other third-party or cross-site subresource which means that any SameSite=Strict
or SameSite=Lax
cookies will be blocked.
Additionally, even if the browser does allow resources from insecure schemes to be loaded on a secure page, all cookies will be blocked on these requests as third-party or cross-site cookies require Secure
.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict | ⛔ Blocked | ⛔ Blocked |
SameSite=Lax | ⛔ Blocked | ⛔ Blocked |
SameSite=None;Secure | ✓ Allowed | ⛔ Blocked |
Posting between cross-scheme versions of a website would previously allow cookies set with SameSite=Lax
or SameSite=Strict
to be sent. Now this is treated as a cross-site POST—only SameSite=None
cookies can be sent. You may encounter this scenario on sites that present the insecure version by default, but upgrade users to the secure version on submission of the sign-in or check-out form.
As with subresources, if the request is going from a secure, e.g. HTTPS, to an insecure, e.g. HTTP, context then all cookies will be blocked on these requests as third-party or cross-site cookies require Secure
.
Warning: The best solution here is to ensure both the form page and destination are on a secure connection such as HTTPS. This is especially important if the user is entering any sensitive information into the form.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict | ⛔ Blocked | ⛔ Blocked |
SameSite=Lax | ⛔ Blocked | ⛔ Blocked |
SameSite=None;Secure | ✓ Allowed | ⛔ Blocked |
Developer tooling and messaging are available in Chrome and Firefox.
From Chrome 86, the Issue tab in DevTools will include Schemeful Same-Site issues. You may see the following issues highlighted for your site.
Navigation issues:
Subresource loading issues:
More detail is available in Testing and Debugging Tips for Schemeful Same-Site.
From Firefox 79, with network.cookie.sameSite.schemeful
set to true
via about:config
the console will display message for Schemeful Same-Site issues. You may see the following on your site:
cookie_name
will be soon treated as cross-site cookie against http://site.example/
because the scheme does not match."cookie_name
has been treated as cross-site against http://site.example/
because the scheme does not match."It's possible that some of your links and subresources still point to insecure URLs.
One way to fix this issue is to use HTTP Strict-Transport-Security (HSTS) and the includeSubDomain
directive. With HSTS + includeSubDomain
even if one of your pages accidentally includes an insecure link the browser will automatically use the secure version instead.
While we strongly recommend that you upgrade your site entirely to HTTPS to protect your users, if you're unable to do so yourself we suggest speaking with your hosting provider to see if they can offer that option. If you self-host, then Let's Encrypt provides a number of tools to install and configure a certificate. You can also investigate moving your site behind a CDN or other proxy that can provide the HTTPS connection.
If that's still not possible then try relaxing the SameSite
protection on affected cookies.
SameSite=Strict
cookies are being blocked you can lower the protection to Lax
.Strict
and Lax
cookies are being blocked and your cookies are being sent to (or set from) a secure URL you can lower the protections to None
.SameSite=None
requires the Secure
attribute on cookies which means those cookies may not be sent or set over an insecure connection. In this case you will be unable to access that cookie until your site is upgraded to HTTPS.SameSite
attribute? #Cookies without a SameSite
attribute are treated as if they specified SameSite=Lax
and the same cross-scheme behavior applies to these cookies as well. Note that the temporary exception to unsafe methods still applies, see the Lax + POST mitigation in the Chromium SameSite
FAQ for more information.
WebSocket connections will still be considered same-site if they're the same secureness as the page.
Same-site:
wss://
connection from https://
ws://
connection from http://
Cross-site:
wss://
connection from http://
ws://
connection from https://
Photo by Julissa Capdevilla on Unsplash