The modern web relies a lot on cookies. However, we are not talking about sweet pieces of pastry you can eat. Instead, cookies are pieces of information a website stores on the user’s device. If you have a website, you can mark a cookie to be an HttpOnly Cookie. If you want to know what does this means or why should you use this type of cookie, you are in the right place.
The HttpOnly Cookie
What is a Cookie?
Before we can explain what is an HttpOnly Cookie, we should clarify what a traditional cookie is. If you already know that, feel free to skip this part.
A cookie is a piece of text that a website tells your PC to store for later use. Remember that a website can only suggest that to your browser (e.g. Chrome, Firefox), but it cannot force the cookie to be saved. Instead, it is the browser deciding if it should accept cookies or not, and you can configure that in any modern browser. However, browsers accept cookies by default because the web heavily relies on them.
A cookie doesn’t simply mean saving some piece of data in your browser. It also means sending that piece of data in every request to the site that created the cookie. This becomes pretty useful, for example for authentication. With a cookie, you can store a token that identifies the user. Then, every time the browser makes a request to your site, it will send the authentication token. Now, on your web server, you can recognize users by their token (their cookie).
HttpOnly Cookie
HttpOnly is a flag the website can specify about a cookie. In other words, the webserver tells your browser “Hey, here is a cookie, and you should treat is as HttpOnly”.
An HttpOnly Cookie is not accessible by the JavaScript. Only the browser knows about it, and it doesn’t give it to the JavaScript code in the page. At first, it might sound like a limitation, and it is. However, the goal of that is that we cannot trust the JavaScript code. An attacker may use JavaScript to steal our authentication token stored in a cookie, and then access the website with our account. With HttpOnly cookies, this is not possible. This makes XSS attacks (the one we just described) harder to perform.
It is a recognized best practice to share any authentication data only with HttpOnly cookies. Using a standard cookie for authentication is a known vulnerability we should avoid in any case.
Diving deeper
In the end, cookies are a property of HTTP. HTTP is a standard protocol that defines how to send and receive cookies. Luckily, the instructions of HTTP are in plain text. To set a cookie as HttpOnly, the instruction to use in the header is the following.
Set-Cookie: =[; =][; expires=][; domain=][; path=][; secure][; HttpOnly]
If you are not familiar with this syntax, it provides several options. One of them is HttpOnly, and we should add in our case. The simplest way to make an HttpOnly Cookie is thus the following.
Set-Cookie: cookie_name="cookie_value"; HttpOnly
Of course, creating cookies from a programming language you will not have to write HTTP headers manually. You will have a dedicated function to create cookies, check the documentation of your programming language.
HttpOnly Cookies are a matter of trust
As we said in the beginning, cookies are suggestions the website tells to your browser. In the end, is the browser to decide whether to accept a cookie or not. Like so, it is also the browser to decide to provide the cookie to JavaScript or not. To put it simply, when you make an HttpOnly Cookie, you are telling the browser “Please, don’t show that to JavaScript”. Thus, trust HttpOnly cookies blindly. Most importantly, don’t use to store sensitive data like credentials or passwords: use only tokens.
However, be aware that all modern browsers implement HttpOnly cookies. In fact, Internet Explorer 6 started to support them in 2002. Even today, this technology is still relevant.
In Conclusion (and TL;DR).
HttpOnly Cookies are Cookies that are not available to JavaScript. Thus, they are the best choice for storing session tokens. To implement them, you should check the reference of your programming language, but in general, it is as simple as adding an additional parameter to a function.
If you want to make your web application more secure, making sessions based on an HttpOnly cookie is a good start. What to do next? A good start could be reading some articles of the Open Web Application Security Project, which dictates some of the best practices in the field.
What do you think about HttpOnly Cookies? Did you know about the vulnerabilities implied in not using them? Let me know your opinions in the comments.
