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 each other.

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.

Issue Titles

• 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 subresources
  • 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"

Types of Issues

Note: Two urls with the same registrable domain but different schemes are termed cross-scheme to each other.

Navigation Issues

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.

Subresource Issues

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 subresource which means that any SameSite=Strict or SameSite=Lax cookies will be blocked.

POSTing Issue

Posting between cross-scheme versions of a website would previously allow cookies set with SameSite=Strict or 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.

Because 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.

Debugging Tips

Please see this page for more information on how to debug your site.

How to Resolve

Upgrade to HTTPS

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.

Unable to Upgrade to HTTPS

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=Strict cookies are being blocked you can lower the protection to SameSite=Lax.
• In cases where both SameSite=Strict and SameSite=Lax cookies are being blocked and your cookies are being sent to (or set from) a secure URL you can lower the protections to SameSite=None.
  • This workaround will fail if the URL you’re sending cookies to (or setting them from) is insecure. This is because SameSite=None requires the Secure attribute 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.