HTTP is a stateless protocol. Cookies are the most common way to make a conversation between a browser and server stateful.

A website sets a cookie by specifying one or more Set-Cookie headers in the HTTP response. Subsequent requests by the browser to same domain will include the same data in the Cookie header of the HTTP requests (providing various security restrictions are met). The cookie information will continue to be sent in HTTP requests until the cookie expires, or a new Set-Cookie cookie is received. In this way, the server can track which user-agent it is talking to.

Cookies are often used to establish a session between the website and browser. The user authenticates themselves as a one-time process, and thereafter a token is passed back in the cookie so the site knows which user a HTTP request is coming from. Because of this, many attacks on websites try to steal or manipulate cookie data. For example:

  • If an attacker can forge cookie data, they can fool a site into making them believe they are another user, leading to privilege escalation vulnerabilities.

  • If an attacker can inject JavaScript into a web application, they may be able to steal another user’s cookie and impersonate them.

  • If an attacker can intercept HTTP traffic using a man-in-the-middle-attack, they may be able to steal another user’s cookie and impersonate them.

To mitigate the risk of this type of attack, consider doing the following:

  • Set your cookies to be Secure, so they can only sent over HTTPS. This will prevent all but the most sophisticated man-in-the-middle-attacks.

  • Set your cookies to be HTTPOnly, so they cannot be read or manipulated by JavaScript. This prevents the possibility of your user’s cookies being stolen if your site is vulnerable to XSS.

  • Tamper-proof or encrypt cookie data, so manipulated cookie data is rejected.

  • Make sure your session IDs are unguessable.