> For the complete documentation index, see [llms.txt](https://riteshs4hu.gitbook.io/infosec-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://riteshs4hu.gitbook.io/infosec-notes/web-appsec/web-application-fundamentals/cookies-vs-session-vs-token.md).

# Cookies vs Session vs Token

## **What is a Cookie?**

A **cookie** is a small piece of data stored in a user's web browser (client-side) and sent to the server with each request. It helps websites remember users, maintain sessions, and track browsing activity. They consist of a **name-value pair** and have additional attributes such as **domain, path, expiration, secure, HttpOnly, and SameSite**.

***

### **Cookie Attributes**

#### **1. Name and Value**

* Cookies have a **name** (e.g., `"username"`) and a corresponding **value** (e.g., `"JohnDoe"`) to store specific information.

#### **2. Domain**

* Specifies which websites can access the cookie.
* It Can be restricted to a specific domain or multiple subdomains.

#### **3. Path**

* Determines which pages or directories on a website can access the cookie.

#### **4. Expiration**

* Defines how long the cookie should be stored before it expires.
* If not set, it becomes a **session cookie** and gets deleted when the browser closes.

#### **5. Secure**

* Ensures that the cookie is only transmitted over **secure (HTTPS) connections**.

#### **6. HttpOnly**

* Prevents client-side scripts (JavaScript) from accessing the cookie, and security against **XSS (Cross-Site Scripting) attacks**.

#### **7.** [**SameSite**](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#controlling_third-party_cookies_with_samesite) **(Strict, Lax, None)**

* Controls whether cookies are sent with cross-site requests to prevent **CSRF (Cross-Site Request Forgery)** attacks.
  * **Strict** – Cookies are not sent with any cross-site request.
  * **Lax** – Cookies are sent with top-level navigations but not embedded content.
  * **None** – Cookies are sent with all cross-site requests (must be `Secure`).

***

### **Where to Find Cookies in a Web Browser?**

1. **Visit the website/application**
2. **Open Developer Tools** (`Ctrl + Shift + I` or `F12`)
3. **Go to "Application" Tab → Storage → Cookies**

***

### **How Cookies Work?**

1. A user visits a website (`example.com`).
2. The server sends a `Set-Cookie` header in the HTTP response:

   ```
   Set-Cookie: sessionID=abc123; HttpOnly; Secure; SameSite=Strict; Path=/
   ```
3. The browser stores the cookie.
4. On subsequent requests, the browser includes the cookie in the request headers:

   ```
   Cookie: sessionID=abc123
   ```
5. The server reads the cookie and identifies the user.

***

## **What is a Session?**

A **session** is a mechanism used to maintain user authentication and stateful information between the client and the server. Unlike cookies, which store data on the **client side**, sessions store a **unique identifier (session ID)** on the **server** (e.g., in memory, databases, or files).

When a user logs in:

* A **session ID** is generated and stored on the **server**.
* This session ID is then sent to the **client (browser)**, usually in a **cookie**.
* The server uses this session ID to identify and authenticate the user during their visit.

#### **Difference Between Cookies and Sessions**

* **Cookies**: Stored **only on the client-side** and sent with every request. The server reads the cookie and processes the request.
* **Sessions**: Stored **on the server** and the session ID is used to verify the legitimacy of the session before processing requests.

***

### **How do Sessions work?**

1. **User Logs In** → The server creates a unique **session ID**.
2. **Session ID Sent to Client** → Stored in a cookie (`Set-Cookie: sessionID=xyz123`).
3. **Client Makes Requests** → The browser sends the session ID with each request (`Cookie: sessionID=xyz123`).
4. **Server Verifies Session** → The server retrieves stored session data and authenticates the user.
5. **Session Expiry or Logout** → The session is **destroyed** when the user logs out or after a timeout.

***

## **What is a Token?**

A **token** is a mechanism used for authentication and authorization in modern applications. It allows users to securely authenticate across **multiple servers or APIs** without relying on session-based authentication.

Unlike **cookies** (which store data on the client) and **sessions** (which store data on the server), **tokens** provide a **stateless** authentication method. This means the server does not need to store user sessions. Authentication is verified by **validating the token itself** with each request. Unlike cookies, the server does not rely on storing session data; instead, it verifies the token and proceeds with the request.

***

### **How do Tokens work?**

1. **User Logs In** → The server authenticates the user and generates a **token** (e.g., JWT, OAuth token).
2. **Token Sent to Client** → The token is stored on the client (in `localStorage`, `sessionStorage`, or a secure cookie).
3. **Client Makes API Requests** → The token is sent with each request in the `Authorization` header (`Bearer <token>`).
4. **Server Verifies Token** → The server validates the token's **signature**, **expiration**, and other claims.
5. **Access Granted or Denied** → If the token is valid, the request is processed; if invalid or expired, authentication fails.

***

#### References

{% embed url="<https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies>" %}

{% embed url="<https://www.geeksforgeeks.org/difference-between-session-and-cookies/>" %}