Diving deep into cookie security


image-source: instructables.com

Application’s security is all the organisations are concern and focused on. In edition to make an app more secure, developers try all the tactics from here and there but in the process of that they ignore the basics. Cookie is one of it. Securing cookie can do half of the job for them but it is ignored continuously till date. Cookie is the root cause for so many attacks from XSS to CSRF. There are plenty of myths and misconceptions about cookie. So, why not we clear the air and take a deep dive into cookie security and understand how important and critical it is.

What is Cookie?

A cookie is a small piece of data that a server sends to the user's web browser. The browser may store it and send it back with the next request to the same server. Cookies let us get around the statelessness of the HTTP protocol by storing data at the client-side. Usually the cookies are set using Set-cookie in the HTTP header. Set-Cookie: [cookie-name]=[cookie-value]

This header educates the web browser to store the cookie and send it back in future requests to the server. Cookies are normally used as a data storage or as a token of authentication, session management and tracking as well at some extent.

Cookies are actually simply key/value pairs that let us get around HTTP being a stateless protocol. When a developer has got the info they wish to last for more than one connection they can use cookies to store that data on the client side. While this tends to get handled by the programming language being used it is accomplished using HTTP headers.

What does the cookie contains?

Cookie has got several attributes- HTTPOnly, Secure, Path, Domain and Expires. All these attributes stands for something. Let’s have a glance on them.

HTTPOnly and Secure:

A secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Even with Secure, sensitive information should never be stored in cookies, as they are inherently insecure and this flag can't offer real protection.

Path and Domain:

The Domain and Path attributes define the scope of the cookie. Talking about the scope means what URLs the cookies should be sent to.

Domain specifies allowed hosts to receive the cookie. If unspecified, it defaults to the host of the current document location, excluding subdomains. If Domain is specified, then subdomains are always included. The issue for Internet Explorer browser is it will include subdomains as well in the scope.

i.e, if Domain=abc,com is set, then cookies are included on subdomains like app1.abc.com

Path indicates a URL path that must exist in the requested URL in order to send the Cookie header. The %x2F ("/") character is considered a directory separator, and subdirectories will match as well.


Expires is used for setting persistent cookies. It informs how long the browser should use the persistent cookie and when the cookie should be deleted. If this attribute is not specified, then the lifetime of the cookie is the same as that of browser session.

SameSite cookies allow servers require that a cookie shouldn't be sent with cross-site requests, which somewhat protects against cross-site request forgery attacks. The irony is SameSite cookies are still experimental and not yet supported by all browsers.

Misconceptions about cookie attributes

Cookies marked with the ‘Secure’ attribute are only sent over encrypted HTTPS connections and are therefore safe from man- in-the-middle attacks.

Cookies marked with the ‘HttpOnly’ attribute are not accessible from JavaScript and therefore unaffected by cross-site scripting (XSS) attacks.

The ‘Path’ attribute limits the scope of a cookie to a specific path on the server and can therefore be used to prevent unauthorised access to it from other applications on the same host.

The ‘Domain’ attribute should be set to the origin host to limit the scope to that particular server. For example if the application resides on server app.abc.com, then it should be set to domain=app.abc.com

What’s the best solution for cookie security?

You’ve to keep your cookies safe to avoid session hijacking, sniffing and XSS attacks and to achieve that first thing you’ve to keep in mind is BROWSERS. Your cookie security must incorporate with the browser versions. For example, SameSite cookie header is not supported by all the browsers which is ideally used to avoid cross origin attacks i.e, CSRF.

The third party cookies are also used which sometimes ends up disclosing your tracking and privacy state. So this is one more area of focus where the developers need to identify the scope and must not use this kind of cookies. Even if they have to use, precautionary steps needs to be followed and user consent must be obtained.

HTTPOnly, Secure, Path, Domain and Expires attributes should be in place with correct configuration rather than following the Jack and Johnny approach.

SameSite attribute is a good option to use for avoiding adverse attacks like CSRF.



4G LTE attacks

The attacks exploit design weaknesses in three key protocol procedures of the 4G LTE network known as attach, detach, and paging.


Wifi Security Protocols

In today’s world Wi-Fi has become the essential thing in our daily routine. The wireless networks are also not secure in this digital age.