Skip to main content

HTTP Cookies

An HTTP cookie is a tiny (tracking) information stored on the user's computer usually in the web browser while the user is browsing a website. In a technical terms, it is created by an HTTP response from a web server to a client's browser, in a HTTP response header called Set-Cookie. The browser, in turn, stores this cookie for the specified duration, and sends it back to the server with next set of requests in an HTTP header called Cookie.

HTTP Response

Set-Cookie: sessionId=abc123; Expires=Wed, 09 Jun 2023 10:18:14 GMT

In this example, sessionId=abc123 is the actual data being stored, and Expires is an attribute specifying when the cookie will expire.

HTTP Request

Corresponding to the above, the following HTTP Header is sent in all the subsequent client requests:

Cookie: sessionId=abc123

Types of Cookies​

  • Session Cookies are temporary and expire automatically when you close your web browser.
  • Persistent Cookies remain on your device for a set period or until manually deleted. They typically have long expiry dates and used for various purposes, like remembering login details or preferences.

HTTP Only​

This attribute instructs the browser to prevent client-side scripts from accessing the cookie data, thus securing it from potential cross-site scripting (XSS) attacks. It helps to protect sensitive data (e.g., session identifiers) from being compromised by malicious scripts.

Set-Cookie: SessionId=xyz123; HttpOnly

Secure​

The Secure attribute mandates the clients to ensure these cookies are sent over secure, encrypted connections only, such as HTTPS. This prevents cookie theft via man-in-the-middle (MITM) attacks.

Example:

Set-Cookie: id=a3fWa; Secure

SameSite​

The SameSite attribute controls whether a cookie is sent with cross-site requests, providing some protection against cross-site request forgery (CSRF) attacks. It has three settings: Strict, Lax, and None.

  • Strict prevents the cookie from being sent on all cross-site requests.
  • Lax allows cookies on safe HTTP methods (e.g., GET) from external sites.
  • None permits cookies to be sent with all cross-site requests, but requires Secure to be set.
Set-Cookie: widget_session=abc123; SameSite=Lax

Expires and Max-Age​

The Expires attribute sets a specific date/time for when the cookie will be deleted. The Max-Age attribute specifies the duration (in seconds) the cookie will live. If both are set, Max-Age has precedence.

Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT
Set-Cookie: theme=light; Max-Age=604800; // 1 week from now

Domain​

The Domain attribute specifies the domain for which the cookie is valid. When you set the Domain attribute to a specific domain, the browser will include the cookie in HTTP requests to that domain and its subdomains. Example:

Set-Cookie: id=a3fWa; Domain=example.com

Note: This is not designed to accept multiple, distinct domain names in a single Set-Cookie header.

Path​

The Path attribute defines the relative path within the domain that this cookie is valid for. Put in simple terms, restricts the cookie access and transmission to a specific directory path.

Set-Cookie: user=JohnDoe; Path=/accounts

The Role of Cookies in Web Browsing​

Cookies are vital for creating a seamless and personalized web browsing experience. They enable functionalities like keeping users logged into a website, remembering shopping cart items, and preserving user preferences across sessions.

Challenges & Limitations With HTTP Cookies​

While HTTP cookies are a foundational component of web browsing, they come with several limitations that affect their efficiency and security.

  1. Size Limitations: Each cookie has a size limit, typically around 4KB. This limit constrains the amount of information that can be stored in a single cookie. Additionally, browsers limit the number of cookies that can be stored per domain, usually between 50 and 300 cookies.
  2. Domain and Path Constraints: Cookies are restricted to the domain and path that set them. This means a cookie set by one domain cannot be accessed by another domain, which is a fundamental security feature.
  3. Cross-Origin Resource Sharing (CORS) Issues: Cookies adhere to the same-origin policy, meaning they can only be sent to the same domain that set them. In cases where resources need to be accessed from different domains (cross-origin), managing cookie permissions becomes complex. There are solutions using CORS headers but can prove to be challenging to implement correctly.
  4. Security Concerns: Cookies can be vulnerable to various security attacks, including:
    • Cross-Site Scripting (XSS): Malicious scripts injected into websites can access cookies, leading to data theft or session hijacking.
    • Cross-Site Request Forgery (CSRF): Attackers can trick a user's browser into sending a request with the user's cookies, potentially leading to unauthorized actions on a web application.
    • Man-in-the-Middle Attacks: Unencrypted cookies can be intercepted and read by attackers, especially on unsecured HTTP connections.
  5. Performance Issues: Cookies are sent with every HTTP request to the server, which can increase the amount of data transferred, thereby affecting the website's load time.
  6. Dependency on User Settings: Cookies rely on browser settings and user permissions. Users can disable cookies, clear them, or use incognito modes, which affects the persistence and reliability of cookie-based functionalities.
  7. Privacy Implications: The use of tracking cookies for monitoring user behavior has raised significant privacy concerns. Users and regulatory bodies are increasingly wary of cookies that track browsing habits or collect personal data without explicit consent.

Evolving Web Standards​

As web standards evolve and new technologies emerge, cookies may become less relevant. The rise of HTML5 and other storage options like local storage, session storage, and indexedDB provide alternative methods for storing data on the client side.