Read more about the secure attribute and other ways of securing cookies below.
Secure cookies security assessment
CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
What are cookies, and how do they work?
In a nutshell, browser cookies (web cookies) are a piece of data sent by the server to the client where they may be stored. For example, when a server receives an HTTP request, it can include one or several Set-Cookie headers as part of the response.
Later, the browser may return the cookie inside a header when requesting to prove that the subsequent request is coming from the same source as at an earlier time. This allows users to remain logged in to an application instead of logging in every time they make a new request to a server.
Besides session management, HTTP cookies are also used to remember user preferences and settings and track user behavior.
What is a secure cookie?
Cookies can be configured to have different qualities using several attributes. For example, they can be set up to have a specific lifetime, i.e., to expire after a particular time, using the Expires and Max-Age attributes. They can also be limited to specific domains or paths through the Domain and Path attributes.
In addition, cookies can be configured to be sent securely by using different attributes such as the Secure attribute and others.
This attribute prevents cookies from being accessed by unauthorized parties or scripts. In addition, it guarantees that when the client sends the cookie, it does so through an encrypted request, using the HTTPS protocol.
A secure cookie can only be set by sites that use the HTTPS protocol and can only be sent to such sites by browsers. When the secure attribute is enabled, browsers will prevent cookies from being sent over unencrypted channels. This guarantees the confidentiality of the cookie and its contents when exchanged between client and server.
Because secure cookies are vulnerable to some exploits, further attributes can be used with or instead of the Secure attribute. These are the HttpOnly attribute and the SameSite attribute.
Even with this attribute, a cookie will remain vulnerable to cross-site tracing (XST) and cross-site request forgery (CSRF) attacks.
The SameSite attribute protects against CSRF attacks as it lets servers specify when cookies can be sent in response to cross-site requests. The attribute has three possible values to determine how strongly it should be enforced. These are Strict, Lax, and None.
The Strict value allows a cookie only to be sent to the site from which it originated. Lax allows cookies to be sent to a target domain even if it is different from the cookie’s origin, but only in cases of safe requests such as GET, not third-party cookies. None allows cookies to be sent in cases of both originating and cross-site requests, i.e., third-party. However, it does require this to occur in a secure context, i.e., via the use of the Secure attribute.
Why do insecure cookies create vulnerabilities?
Cookies not sent over encrypted channels can be picked up by anyone eavesdropping on a connection. This would allow a party to steal the cookies and read their contents.
If the cookie contains sensitive information such as authentication details, an attacker could impersonate the victim, hijack their session, and potentially steal more data or exploit user privileges.
Do secure cookies have vulnerabilities?
While the above attributes are undoubtedly helpful, their security mainly applies to the cookie’s confidentiality. For example, suppose someone has access to the client’s hard drive. In that case, they can still access the cookie and modify its information, disrupting its integrity, also known as “weak integrity.”
The weak integrity problem of cookies is addressed in the Common Weakness Enumeration under CWE-565 and CWE-784, among others. It refers to the danger of relying on cookies without proper validation and integrity checking and using such cookies to make security-critical operations.
These and other types of inherent vulnerabilities and security considerations make even secure cookies vulnerable in several instances. Attacks that can be used to compromise cookies include cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks, and more.
For this reason, some browsers do not use the Secure attribute and do not allow HTTP sites even to set cookies with this attribute. And regardless of whether these attributes are used, some sources recommend not storing any sensitive data in cookies.
How to Enable Secure Cookies
To set cookies to secure an HTTP-only, you need to configure the web framework which issues the cookies. To configure secure cookies in PHP or Django, see the guides below. To set the secure cookie attribute in Java, ASP.NET, and other frameworks, see the OWASP Secure Cookie Attribute page.
In PHP, configure the cookie settings for all delivered websites. Set the following in your /etc/php/php.ini file:
session.cookie_secure = 1 session.cookie_httponly = 1
In Django, make the following cookie settings in your projects preferences file:
What does Secure do on a cookie?
The Secure attribute guarantees that cookies will only be sent via encrypted channels using the HTTPS protocol. If a cookie has this attribute, a server will not send it to a website that does not support HTTPS.
Are secure cookies safe?
Secure cookies are not without vulnerabilities. However, this attribute offers protection by ensuring that cookies and the sensitive data they may contain are only exchanged between browsers and websites through an encrypted channel.
What is the use of the HttpOnly cookie?