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:

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?

  • 1
    Just pointing out / clarifying that the secure flag prevents cookies from being sent on insecure connections. What do you mean when you state that they can still be deleted from an insecure site ?
    – niilzon
    May 8, 2017 at 10:55
  • 1
    @niilzon, secure attribute ensures confidentiality but not the integrity. Consider abc.test.com and def.test.com. abc.test.com can set a cookie with domain as test.com which can possibly overwrite, say, a secure, test.com cookie set by def.test.com
    – one
    May 8, 2017 at 11:36

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .