Strict secure cookies vs. cookie prefixes

Question

The secure flag on cookies prevent them from being read by an insecure (non-HTTPS) site, but they can still be written or deleted from an insecure site. There are two new browser features that try to prevent that:

• Strict Secure Cookies
• Cookie Prefixes

It seems to me that the __Secure- prefix also makes the cookie strictly secure.

How do these two features compare with each other? Why are there two seperate solutions for overwriting cookies? Do I still need the cookie prefix if my clients have a browser with strict secure cookie support?

Answer 1

The strict secure cookies draft describes a limitation of strict secure cookies where cookie prefixes can help:

The mitigations in this document do not, however, give complete confidence that a given cookie was set securely. If an attacker is able to impersonate a response from "http://example.com/" before a user visits "https://example.com/", the user agent will accept any cookie that the insecure origin sets, as the "secure" cookie won't yet be present in the user agent's cookie store. An active network attacker may still be able to use this ability to mount an attack against "example.com", even if that site uses HTTPS exclusively.

If there is no cookie yet, an insecure origin can set a secure cookie, but not a prefixed cookie. So cookie prefixes are still a good idea when using browsers that implement strict secure cookies.