This feature adds a set of restrictions upon the names which may be used for cookies with specific properties. These restrictions enable user agents to smuggle cookie state to the server within the confines of the existing "Cookie" request header syntax, and limits the ways in which cookies may be abused. In a nutshell: `__Secure-` cookies have to have the `Secure` flag, and `__Host-` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter).
Cookie prefixes make it possible to flag your cookies to have different behavior, in a backward compatible way. It uses a dirty trick to put a flag in the name of the cookie. When a cookie name starts with this flag, it triggers additional browser policy on the cookie in supporting browsers.
The __Secure- prefix makes a cookie accessible from HTTPS sites only. A HTTP site can not read or update a cookie if the name starts with __Secure-. This protects against the attack we earlier described, where an attacker uses a forged insecure site to overwrite a secure cookie.
I would consider a browser that allows a cookie with a secure flag to be overwritten from a http page buggy, and thus the solution would be simply enforcing the secure flag in a same way.
What legitimate use is there for overwriting a secure cookie with a non secure one?
Yes, exactly. After setting a cookie server usually cannot check if it is secure or not but using this prefix on modern browsers guarantees to server that the cookie is certainly secure. Of course it works only in modern browsers but it's part of defense in depth.
This feature adds a set of restrictions upon the names which may be used for cookies with specific properties. These restrictions enable user agents to smuggle cookie state to the server within the confines of the existing "Cookie" request header syntax, and limits the ways in which cookies may be abused. In a nutshell: `__Secure-` cookies have to have the `Secure` flag, and `__Host-` cookies have to have `Path=/`, can't have `Domain`, and might require `Secure` (depending on the setter).
From: https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/
Cookie prefixes make it possible to flag your cookies to have different behavior, in a backward compatible way. It uses a dirty trick to put a flag in the name of the cookie. When a cookie name starts with this flag, it triggers additional browser policy on the cookie in supporting browsers.
The __Secure- prefix makes a cookie accessible from HTTPS sites only. A HTTP site can not read or update a cookie if the name starts with __Secure-. This protects against the attack we earlier described, where an attacker uses a forged insecure site to overwrite a secure cookie.