Schemeful Same-Site DevTools Issues
Schemeful Same-Site is a change which further protects your website from CSRF
attacks by distinguishing between the insecure and secure versions of it.
Meaning that an attacker which takes control of http://bank.example isn't able
to trick a user into clicking a link and sending
SameSite=Strict cookies to
https://bank.example, potentially logging in and draining the user's account.
Schemeful Same-Site makes it so that http://bank.example and
https://bank.example are considered cross-site to each other; just like how
https://bank.example and https://shopping.example are considered cross-site to
To determine which, if any, of your website's cookies are affected you can check the DevTools Issue Tab for any issues that pop up on your site.
If you see any of the following issue titles then that means one of your website's cookies is going to be/was blocked. See the relevant section for each issue title below to see what could be causing this and the "How to Resolve" section how you can resolve it.
- Migrate entirely to HTTPS to continue having cookies sent on same-site requests
- Migrate entirely to HTTPS to have cookies sent on same-site requests
If you see either of these titles then this issue is caused by a navigation. See the navigation section within "Types of Issues"
- Migrate entirely to HTTPS to continue having cookies sent to same-site subresources
- Migrate entirely to HTTPS to continue allowing cookies to be set by same-site subresources
- Migrate entirely to HTTPS to have cookies sent to same-site subresources
- Migrate entirely to HTTPS to allow cookies to be set by same-site
- In a rare case this may also occur while POSTing a form. See the POSTing section within "Types of Issues"
If you see any of these titles then this issue is caused by a subresource. See the subresource section within "Types of Issues"
Note: Two urls with the same registrable domain but different schemes are termed cross-scheme to each other.
Navigating between cross-scheme versions of a website would previously allow
SameSite=Strict cookies to be sent. Now this is treated the same as a navigation from an entirely different website which means
SameSite=Strict cookies will be blocked from being sent.
Loading a cross-scheme subresource on a page would previously allow
SameSite=Lax cookies to be sent or set. Now this is
treated the same way as any other third-party subresource which means that any
SameSite=Lax cookies will be blocked.
Posting between cross-scheme versions of a website would previously allow
cookies set with
SameSite=Lax to be sent. Now this is
treated the same as a POST from an entirely different website which means only
SameSite=None cookies can be sent.
SameSite=None require the
Secure attribute on cookies, this can only
be done from HTTP to HTTPS. The other way, HTTPS to HTTP, will not work as
cookies with the Secure attribute cannot be sent to insecure URLs.
Please see this page for more information on how to debug your site.
The best way to resolve these issues is to make sure your entire site is upgraded to HTTPS. Once this is the case none of your cookies will be affected by Schemeful Same-Site.
While we strongly recommend that you upgrade your site entirely to HTTP 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 that’s still not possible then a workaround you can try is relaxing the
SameSite protection on affected cookies.
- In cases where only
SameSite=Strictcookies are being blocked you can lower the protection to
- In cases where both
SameSite=Laxcookies are being blocked and your cookies are being sent to (or set from) a secure URL you can lower the protections to
- This workaround will fail if the URL you’re sending cookies to
(or setting them from) is insecure. This is because
Secureattribute on cookies which means those cookies may not be sent or set to a insecure URL. In this case you will be unable to access that cookie until your site is upgraded to HTTPS.
- This workaround will fail if the URL you’re sending cookies to (or setting them from) is insecure. This is because