This content originally appeared on DEV Community and was authored by ZeeshanAli-0704
Cookies are the backbone of state management on the web. They help websites remember who you are, what’s in your shopping cart, or what theme you prefer. But beyond the basics of document.cookie, cookies have many properties that control their scope, security, and behavior across domains.
This blog is a deep dive into cookie properties — from Expires to SameSite and how cross-origin rules affect them.
📑 Table of Contents
- Introduction
- Basic Structure of a Cookie
-
Cookie Properties Explained
- Name=Value
- Expires and Max Age
- Domain
- Path
- Secure
- HttpOnly
- SameSite
- Priority
- Partitioned Cookies (CHIPS)
Cookies and Cross Origin Rules
Real World Examples
Best Practices
Conclusion
🔹 Introduction
A cookie is a small key-value pair stored in the browser. While the basics are simple (name=value), the true power of cookies lies in their properties. These properties control lifetime, accessibility, domain scope, cross-site rules, and security.
🔹 Basic Structure of a Cookie
Cookies are set using the Set-Cookie HTTP response header:
Set-Cookie: sessionId=abc123; Expires=Wed, 13 Jan 2027 22:23:01 GMT; Path=/; Domain=example.com; Secure; HttpOnly; SameSite=Strict;
Here:
-
sessionId=abc123→ Name & value -
Expires→ Expiration date -
Path=/→ Cookie available across entire domain -
Domain=example.com→ Scoped to this domain -
Secure→ Sent only via HTTPS -
HttpOnly→ Not accessible from JavaScript -
SameSite=Strict→ Prevents cross-site usage
🔹 Cookie Properties Explained
Name=Value
- The fundamental unit of a cookie.
- Name must be unique within its scope (domain + path).
Example:
Set-Cookie: username=Zeeshan
Expires and Max Age
- Expires: A fixed date/time after which the cookie is invalid.
- Max-Age: Lifetime in seconds (takes precedence over Expires).
Examples:
Set-Cookie: theme=dark; Expires=Wed, 01 Jan 2025 00:00:00 GMT
Set-Cookie: token=xyz; Max-Age=3600
⚡ Session cookies are created if neither Expires nor Max-Age is set (deleted when browser closes).
Domain
- Controls which hosts can receive the cookie.
- By default, cookies are scoped to the exact domain that set them.
- If specified, subdomains can also access it.
Example:
Set-Cookie: userId=123; Domain=example.com
- Accessible to
www.example.com,shop.example.com. - Not accessible to
evil.com.
❌ Security risk: Overly broad domain cookies (like .com) are rejected by browsers.
Path
- Restricts cookie to specific paths.
Example:
Set-Cookie: cart=5; Path=/shop
- Sent with requests to
/shopor/shop/products. - Not sent to
/profile.
Secure
- Cookie only sent over HTTPS.
- Prevents exposure on unencrypted connections.
Set-Cookie: sessionToken=abc; Secure
HttpOnly
- Cookie is inaccessible to JavaScript (
document.cookie). - Helps prevent XSS attacks from stealing cookies.
Set-Cookie: auth=abc; HttpOnly
SameSite
Controls whether cookies are sent with cross-site requests.
-
Strict: Sent only for same-site navigation. Strongest CSRF protection. -
Lax: Sent for top-level navigations (safe by default). -
None: Sent for all requests, must beSecure.
Example:
Set-Cookie: csrftoken=xyz; SameSite=Strict
⚠️ Modern browsers default to SameSite=Lax if not specified.
Priority (Chrome-specific)
Determines eviction order when hitting browser cookie limits:
-
Low,Medium,High.
Set-Cookie: pref=light; Priority=High
Partitioned Cookies (CHIPS)
A new spec: Cookies Having Independent Partitioned State (CHIPS).
- Each third-party cookie is isolated per top-level site.
- Improves privacy by preventing tracking across sites.
Set-Cookie: id=123; Secure; SameSite=None; Partitioned
🔹 Cookies and Cross Origin Rules
1. First Party vs Third Party Cookies
- First-party cookies: Set by the site you are visiting.
- Third-party cookies: Set by external domains (e.g., ad networks).
- Browsers are phasing out third-party cookies due to privacy concerns.
2. Cross Site Request Forgery (CSRF) and SameSite
- Without
SameSite, attackers can force a victim’s browser to send cookies to your site via a malicious request. -
SameSite=StrictorLaxmitigates this.
3. Cross Origin Resource Sharing (CORS) with Cookies
When making cross-origin AJAX requests:
- Server must allow credentials with
Access-Control-Allow-Credentials: true. - Browser must send cookies with
fetch(..., { credentials: "include" }).
Example:
fetch("https://api.example.com/data", {
credentials: "include"
});
Server response must include:
Access-Control-Allow-Origin: https://yourdomain.com
Access-Control-Allow-Credentials: true
🔹 Real World Examples
- Authentication → Secure + HttpOnly session tokens.
-
E-commerce → Shopping cart with
Path=/cart. -
Multi-subdomain apps →
Domain=example.comfor SSO. - Analytics → Third-party cookies (phasing out → CHIPS).
🔹 Best Practices
✅ Use Secure + HttpOnly for auth cookies.
✅ Use SameSite=Lax or Strict to mitigate CSRF.
✅ Avoid overly broad Domain values.
✅ Keep cookies small (<4KB).
✅ Prefer server-set cookies over client-side JS.
✅ For cross-origin APIs, configure CORS properly.
🔹 Conclusion
Cookies may seem simple, but their properties define how they behave in terms of security, scope, and cross-origin interactions. By mastering these attributes — especially SameSite, Secure, and HttpOnly — you can secure your apps, prevent attacks, and ensure a smooth user experience.
The future is moving towards privacy-first cookies (CHIPS, partitioned cookies), so understanding these fundamentals is more important than ever.
More Details:
Get all articles related to system design
Hastag: SystemDesignWithZeeshanAli
Git: https://github.com/ZeeshanAli-0704/SystemDesignWithZeeshanAli
This content originally appeared on DEV Community and was authored by ZeeshanAli-0704
ZeeshanAli-0704 | Sciencx (2025-08-28T16:35:02+00:00) The Ultimate Guide to Cookie Properties in the Browser. Retrieved from https://www.scien.cx/2025/08/28/the-ultimate-guide-to-cookie-properties-in-the-browser/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.