Secure your Cookies (Secure and HttpOnly flags)

Cookies are widely used throughout the Web because they allow publishers to store data directly on the user’s Web browser. They’re particularly used to identify the user’s session, allowing the web server to recognize the user as they navigate through the site, and generally contain sensitive data. You have to properly protect them.

How to secure Cookies

A small reminder: each time a server responds to a request, the HTTP response may contain a Set-Cookie metadata asking the web browser to create one or more cookies associated to one or more domains. Those cookies retain information that will be transmitted in future requests on these domains.

Here is the syntax of such a header:

Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]

Every cookie is identified by its name and retains a value. A lifetime and/or expiry date can be defined, to limit data retention over time. Note that if both attributes are set then the lifetime value (max-age) will prevail.

By default, a cookie is always associated with the location of the current document (domain as well as path) but the Set-Cookie header can define custom values to restrict or extend those hosts to which the cookie will be sent (for example, if a domain is specified, subdomains will be included). Consequently, one of the best practices regarding the security of cookies is to properly manage their scope.

The last 2 attributes, secure and HttpOnly deal specifically with security. Please note that they do not require any associated value: their very presence is enough for the browser to behave as expected when it comes to the cookie.

A cookie can be set and used according to the instruction of a web server, but also directly on the web browser via JavaScript.

In an XSS breach case, an attacker could inject some Javascript, and potentially access to the cookies that, as a reminder, often contain sensitive information. First of all, it is obviously better to prevent the XSS breaches. Then you can avoid those weaknesses to be exploited by defining a Content Security Policy.
The “HttpOnly” flag blocks the cookies usage via Javascript: if an attacker succeeds in injecting some javascript despite all your precautions, he won’t be able to access the cookies anyway. That will significantly limit the attack range.

We regularly recommend it on this blog: your website should use HTTPs. If you have already adopted this protocol and applied our previous advice, you may think that your cookies are protected as they are transmitted through a secure communication and as they can’t be reached in Javascript. Unfortunately, a noticeable issue remains.
What if a user comes to your website via HTTP, simply because he’s typing your URL without mentioning “https://”? This could also happen if your web page contains mixed content.
Setting an HTTP Strict Transport Security (HSTS) header, that will enforce HTTPS usage for all the upcoming visits, will limit the risks related to the first scenario. But all the browsers do not support this header… Still, the first visit remains an issue. About the second scenario, the Content Security Policy can prevent from any mixed content risk with browsers that support “Upgrade Insecure Requests” policy.

Actually, only the secure attribute will let you forbid a cookie to be ever transmitted via simple HTTP.

The interest of this flag is clearly mentioned in the RFC HTTP State Management Mechanism:

Servers that require a higher level of security SHOULD use the Cookie and Set-Cookie headers only over a secure channel. When using cookies over a secure channel, servers SHOULD set the Secure attribute (see Section 4.1.2.5) for every cookie. If a server does not set the Secure attribute, the protection provided by the secure channel will be largely moot.

Obviously, keep in mind that a cookie using this secure flag won’t be sent in any case on the HTTP version of your website. So be careful if your website still has got both HTTPS and HTTP areas.

As a conclusion, do not forget that our web page analysis tool will let you ensure at a glance that all of your cookies are secured, by checking if HttpOnly and secure are properly used!

Tip Cookie Secure Dareboost