DEV Community

Alireza Hassankhani
Alireza Hassankhani

Posted on

Cookie attributes

#webdev #frontend #backend #javascript

🍪

** A Deeper Look at Cookie Attributes**

📦 Set-Cookie Header

When a server wants to create or update a cookie, it uses the Set-Cookie header in the response.

Example of this header:

Set-Cookie: session_id=ab12cd34ef56; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600
Enter fullscreen mode Exit fullscreen mode

At first glance, one might think a cookie is just a Key=Value pair:

session_id=ab12cd34ef56
Enter fullscreen mode Exit fullscreen mode

But in reality, that's only the core part of the cookie.

What the browser actually receives is the Set-Cookie header, which—alongside the main value—includes a set of attributes. These attributes determine:

· Which domain the cookie is valid for
· Which paths it should be sent to
· How long it remains valid
· Whether it should only be sent over HTTPS
· Whether it's accessible via JavaScript
· Whether it should be sent in cross-site requests

Let's examine each of these attributes individually.

🔒 HttpOnly

The HttpOnly attribute specifies that the cookie can only be accessed via the HTTP/HTTPS protocol.

When this attribute is enabled:

· JavaScript cannot access the cookie
· The cookie cannot be read via document.cookie
· The cookie is only sent by the browser when making requests to the server

Why does HttpOnly exist?

One of the most common web attacks is XSS (Cross-Site Scripting).

In this attack, the attacker manages to inject and execute their own JavaScript code on the page. If the cookie does not have HttpOnly set, the attacker can read the user's session cookie and send it to their own server.

Enabling HttpOnly means that even if malicious JavaScript is executed, the session cookie cannot be stolen.

💡 HttpOnly reduces the risk of cookie theft in XSS attacks, but it is not a replacement for preventing the XSS vulnerability itself.

🔐 Secure

The Secure attribute specifies that the cookie should only be sent over a secure HTTPS connection.

If the user is using HTTP, the browser will not send the cookie.

Why does Secure exist?

If a cookie is sent over an unencrypted connection (HTTP), an attacker positioned between the user and the server (Man-in-the-Middle) can eavesdrop on the traffic and view or steal the cookie.

Enabling Secure ensures the cookie is only transmitted over an encrypted connection, drastically reducing the risk of it being stolen in transit.

🌍 Domain

The Domain attribute specifies which domain the cookie is valid for.

For example:

Domain=example.com
Enter fullscreen mode Exit fullscreen mode

In this case, the cookie will be usable for the main domain and, typically, its subdomains as well.

However, if Domain is set to another domain, the browser will not send the cookie for that domain.

This attribute defines the scope of the cookie's validity.

📂 Path

The Path attribute determines which URL paths on the website the cookie should be sent to.

For example:

Path=/admin
Enter fullscreen mode Exit fullscreen mode

In this case, the cookie will only be sent for requests that fall under the /admin path.

This feature ensures the cookie is only used in parts of the site where it's actually needed.

⏳ Expires

The Expires attribute specifies the exact expiration date and time of the cookie.

For example:

Expires=Wed, 01 Jan 2027 00:00:00 GMT
Enter fullscreen mode Exit fullscreen mode

After this date is reached, the browser will delete the cookie.

⌛ Max-Age

The Max-Age attribute specifies the lifetime of the cookie in seconds.

For example:

Max-Age=3600
Enter fullscreen mode Exit fullscreen mode

This means the cookie will be deleted exactly one hour after it was created.

Difference Between Max-Age and Expires

Both are used to determine when the cookie should be deleted, but they have an important difference:

· Expires stores a specific date and time.
· Max-Age specifies the remaining lifetime from the moment the cookie is created.

For this reason, Max-Age is generally considered more reliable, as it does not depend on the user's system clock.

🛡️ SameSite

The SameSite attribute specifies whether the cookie should be sent in requests originating from other sites.

The main purpose of this attribute is to reduce the risk of CSRF (Cross-Site Request Forgery) attacks.

Its common values are:

· Strict → The cookie is only sent in same-site requests.
· Lax → The cookie is sent in most normal requests, but restricts many cross-site requests.
· None → The cookie is sent in all requests; in this case, using Secure is also mandatory.

Proper use of SameSite can be one of the most important defense layers against CSRF attacks.

📌 Summary

Each cookie attribute is designed to solve a specific security or functionality issue:

· HttpOnly → Reduces the risk of cookie theft in XSS attacks
· Secure → Prevents the cookie from being sent over insecure connections and reduces Man-in-the-Middle risks
· SameSite → Reduces the likelihood of successful CSRF attacks
· Domain → Defines which domains are allowed for the cookie
· Path → Defines which URL paths are allowed to receive the cookie
· Expires → Defines the expiration date
· Max-Age → Defines the cookie's lifetime in seconds

Understanding these attributes is one of the most important prerequisites for learning web security, because many common vulnerabilities are directly related to misconfiguring these very options.

Top comments (0)