Menu
They both appear to lock the cookie to a domain, but they are not compatible (in that the use of the __Host prefix necessitates the Domain not being set).
I haven't found a good argument which is the better way to go. I realize that using the Domain attribute has a few features, like allowing subdomains to use the cookie, which seems like the only reason one would use it over __Host.
But all things being equal and assuming that there are no subdomains, can you explain why one would be better than the other?
348
Cookies are only secure in an HTTPS connection. Enforcing the Secure flag ensures that cookies are only sent via an encrypted HTTPS connection. Use of HTTPS prevents disclosure of session ID in person-in-the-middle (MITM) attacks.
From a security perspective, cookies are unlikely to be used maliciously against you as they are just text read by your browser. They don't contain any code that could be executed. However, websites are able to gather a lot of information about you and your website activity.
A cookie's domain attribute determines which domains can access the cookie. Browsers will automatically submit the cookie in requests to in-scope domains, and those domains will also be able to access the cookie via JavaScript.
The __Host- prefix was created to solve a number of security problems associated with cookies and should always be used over the domain attribute. Leaving the domain attribute blank is actually more secure because then your cookie will be sent back only to the same host that set the cookie. This is called the host-only flag in RFC6265:
If the domain attribute is [empty] set the cookie's host-only flag to true.
The __Host- prefix also protects your cookies from being overwritten by web sites hosted on different subdomains of your domain. This is due to the fact that they are also constrained by the host-only flag.
Finally, unencrypted connections leave your web site vulnerable to man-in-the-middle fixation attacks. The __Host- prefix solves this problem by not allowing unencrypted connections to use cookies with this prefix, thus stopping a malicious third party from injecting a set-cookie header with the same name as a secure cookie while users are being redirected from http to https.
If you need to set the domain or path attributes, but still want the security offered by the __Host- prefix, you can use the __Secure- prefix. Like the __Host- prefix, cookies with the __Secure- prefix can only be set from a secure connection.
91
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
