Introduction

HTTP is a stateless application protocol. Each request can be processed independently, and the protocol does not automatically remember that two requests came from the same signed-in user.

Web applications frequently need continuity across requests for:

• User authentication
• Shopping carts
• Language and display preferences
• Multi-step forms
• Authorization context
• Temporary workflow state
• Security and fraud-prevention controls

Cookies and sessions provide mechanisms for maintaining this continuity. A cookie is stored by the user agent and conditionally returned with later requests. A server-side session stores application state on the server and commonly uses a cookie containing an opaque session identifier to associate requests with that state.

In your System Design curriculum, Cookies and Sessions is Topic 3.6 under Networking and Web Request Lifecycle. It follows HTTP/1.1, HTTP/2 and HTTP/3 and precedes WebSockets, Server-Sent Events and long polling.

Prerequisites

Why HTTP Needs State Management

Request 1:

POST /login
Username and password submitted


Request 2:

GET /dashboard


Question:

How does the server know that Request 2
belongs to the user authenticated in Request 1?

The application needs a value that connects later requests to an authenticated session or another state record.

What Is a Cookie?

A cookie is a name-value pair and associated attributes stored by a user agent. A server can send a cookie using the Set-Cookie response field.

HTTP/1.1 200 OK
Set-Cookie: session_id=opaque-random-value; Path=/; Secure; HttpOnly; SameSite=Lax
Content-Type: application/json

{"status":"authenticated"}

On a later eligible request, the browser returns the cookie using the Cookie request field.

GET /dashboard HTTP/1.1
Host: app.example.com
Cookie: session_id=opaque-random-value

Cookie Lifecycle

Server response
      |
      | Set-Cookie
      v
Browser evaluates cookie attributes
      |
      v
Browser stores eligible cookie
      |
      v
Later request matches cookie scope
      |
      | Cookie
      v
Server receives cookie value

Whether the browser sends a cookie depends on attributes such as domain, path, security mode, same-site policy and expiration.

Cookie Attributes

Cookie Domain Scope

Cookie domain rules determine which hosts can receive a cookie.

Host-only Cookie

Set-Cookie: session_id=random-value; Path=/; Secure; HttpOnly

When the Domain attribute is omitted, the cookie is restricted to the host that set it according to the browser's cookie rules.

Domain Cookie

Set-Cookie: preference=compact; Domain=example.com; Path=/

A domain-scoped cookie can be available to eligible subdomains. Session cookies should not receive broader domain scope than the application requires.

Cookie Path Scope

Set-Cookie: admin_session=random-value; Path=/admin; Secure; HttpOnly

The path attribute limits the requests to which the browser includes the cookie.

Cookie path:

/admin


Eligible request paths:

/admin
/admin/
/admin/users


Not an eligible path match:

/courses

Path scope is a browser cookie-delivery control. It should not be treated as an application authorization boundary.

Session and Persistent Cookies

Persistent Cookie Example

Set-Cookie: theme=dark; Max-Age=2592000; Path=/; Secure; SameSite=Lax

A persistent lifetime should reflect the cookie's purpose. Authentication state normally requires stricter lifetime controls than a visual preference.

Secure Attribute

Set-Cookie: session_id=random-value; Secure

The Secure attribute restricts cookie transmission to secure connections.

Set-Cookie: session_id=random-value; Path=/

Set-Cookie: session_id=random-value; Path=/; Secure; HttpOnly; SameSite=Lax

The exact SameSite policy must be selected according to the application's navigation, federation and cross-site requirements.

HttpOnly Attribute

Set-Cookie: session_id=random-value; HttpOnly

The HttpOnly attribute prevents eligible client-side scripts from reading the cookie through applicable cookie APIs.

HttpOnly helps limit session-token theft through injected script, but it does not:

• Prevent every cross-site scripting attack
• Stop malicious script from issuing requests through the user's browser
• Replace output encoding and content security controls
• Protect a token exposed elsewhere
• Replace server-side authorization

SameSite Attribute

The SameSite attribute controls cookie inclusion in cross-site request contexts.

What Is a Session?

A session represents application state associated with a sequence of related requests.

A session can contain:

• Authenticated user identifier
• Authentication time
• Authorization context
• Session creation and last-activity times
• Security-level or authentication-method information
• Temporary workflow state
• CSRF-related state
• Session status

Sensitive state should normally remain on the server. The browser receives an opaque identifier that does not expose the session's internal content.

Server-side Session Flow

User submits credentials
        |
        v
Server verifies credentials
        |
        v
Server creates session record
        |
        v
Server generates random session identifier
        |
        v
Browser receives identifier in secure cookie
        |
        v
Browser sends cookie on later eligible request
        |
        v
Server loads and validates session
        |
        v
Application authorizes requested operation

Example Session Record

Cookies vs Sessions

Session Identifier

A session identifier is commonly a bearer credential. A request presenting a valid identifier can be treated as belonging to the associated session.

A secure session identifier should be:

• Generated by a cryptographically secure random generator
• Unpredictable
• Sufficiently large
• Meaningless outside the server-side lookup
• Protected during transport and storage
• Rotated at important authentication boundaries
• Invalidated according to the session lifecycle

session_id = user_id + current_timestamp

session_id = cryptographically secure random bytes

The identifier contains no:

- User ID
- Email address
- Role
- Timestamp
- Sequential counter

Session ID Rotation

The application should generate a new session identifier when the session's security context changes.

Common rotation points include:

• Successful login
• Privilege elevation
• Administrative-role activation
• Reauthentication
• Account recovery
• Another policy-defined change in trust level

Anonymous session ID
        |
        | Successful authentication
        v
Invalidate or detach old identifier
        |
        v
Generate new authenticated session ID
        |
        v
Return updated session cookie

Rotation helps prevent an identifier established before authentication from remaining the authenticated session identifier.

Session Fixation

Session fixation occurs when an attacker causes a victim to use a session identifier already known to the attacker and the application retains that identifier after authentication.

Attacker obtains or chooses session ID
        |
        v
Victim uses the same session ID
        |
        v
Victim authenticates
        |
        v
Application does not rotate session ID
        |
        v
Attacker reuses known authenticated session ID

Defences include:

• Generating identifiers only through trusted server logic
• Rotating the identifier after authentication
• Rejecting session identifiers supplied through unsupported channels
• Invalidating the previous identifier after rotation

Session Hijacking

Session hijacking occurs when an attacker obtains and successfully reuses a valid session credential.

Possible causes include:

• Network exposure without HTTPS
• Cross-site scripting
• Session IDs recorded in logs
• Session IDs included in URLs
• Insecure browser storage
• Malware or endpoint compromise
• Weak identifier generation
• Overly broad cookie scope
• Long session lifetimes

Session Hijacking Controls

• Use HTTPS throughout the authenticated experience.
• Mark authentication cookies as Secure and HttpOnly.
• Choose an intentional SameSite policy.
• Do not place session identifiers in URLs.
• Prevent sensitive token logging.
• Rotate identifiers after authentication changes.
• Apply idle and absolute expiration.
• Support immediate server-side revocation.
• Use reauthentication for sensitive actions.

Cross-site Request Forgery

Cross-site request forgery, commonly abbreviated as CSRF, takes advantage of a browser automatically attaching authentication cookies to an eligible request initiated from another site.

User is authenticated to trusted.example
        |
        v
User visits another website
        |
        v
Other website triggers request to trusted.example
        |
        v
Browser may attach eligible session cookie
        |
        v
Trusted application receives authenticated request

CSRF defences can include:

• SameSite cookie policy
• Anti-CSRF tokens
• Origin or Referer validation
• Custom request fields for applicable APIs
• Correct use of safe and unsafe HTTP methods
• Reauthentication or confirmation for sensitive operations

Anti-CSRF Token Pattern

Server creates session
        |
        v
Server generates CSRF token
        |
        v
Token is included in trusted form or application state
        |
        v
Client submits token with state-changing request
        |
        v
Server verifies token against session context
        |
        +--> Valid: continue
        |
        +--> Missing or invalid: reject

The CSRF token should be unpredictable, associated with the appropriate security context and validated on applicable state-changing requests.

Session Expiration

Sessions should not remain valid indefinitely.

Session created
      |
      +--> Idle timer updated by qualifying activity
      |
      +--> Absolute expiry remains fixed
      |
      +--> Security event can revoke immediately

The client-side cookie lifetime and server-side session lifetime should be designed together. A browser retaining a cookie does not make an expired or revoked server-side session valid.

Logout

A secure logout process should invalidate the server-side session and instruct the browser to remove the associated cookie.

User requests logout
        |
        v
Server validates current session
        |
        v
Server revokes or deletes session record
        |
        v
Server expires browser cookie
        |
        v
Later use of old session ID is rejected

Cookie Deletion Example

Set-Cookie: session_id=; Max-Age=0; Path=/; Secure; HttpOnly; SameSite=Lax

Cookie deletion should use path and domain scope compatible with the original cookie. Deleting only the client cookie without invalidating the server session can leave a reusable server-side credential.

Session Storage Options

Sessions in a Scaled Application

Browser
   |
   | Session cookie
   v
Load Balancer
   |
   +--> Application Instance A --+
   |                             |
   +--> Application Instance B --+--> Shared Session Store
   |                             |
   +--> Application Instance C --+

A shared session store allows any authorized application instance to load the same session.

The design should address:

• Session-store availability
• Read and write latency
• Expiration and cleanup
• Consistency requirements
• Maximum session size
• Failure and retry behaviour
• Encryption and access control
• Monitoring and capacity

Sticky Sessions

Sticky sessions route a client to the same application instance for subsequent requests according to a load-balancer affinity mechanism.

User A -> Instance 1
User A -> Instance 1
User A -> Instance 1

User B -> Instance 2
User B -> Instance 2

Sticky sessions can simplify local session access but can create:

• Uneven traffic distribution
• Session loss after instance failure
• More complex deployment and scaling behaviour
• Dependence on affinity configuration
• Reduced flexibility when draining instances

Affinity does not replace durable or shared state when sessions must survive instance changes.

Stateful and Self-contained Sessions

A self-contained token is not automatically safer or more scalable. It creates design questions around:

• Revocation
• Token lifetime
• Key rotation
• Claim freshness
• Token audience
• Replay
• Storage location
• Token size

Secure PHP Session Configuration

Configure session-cookie behaviour before starting the PHP session.

<?php

declare(strict_types=1);

$isHttps =
    isset($_SERVER['HTTPS'])
    && $_SERVER['HTTPS'] !== 'off';

if (!$isHttps) {
    http_response_code(400);

    exit(
        'HTTPS is required.'
    );
}

session_name(
    'app_session'
);

session_set_cookie_params([
    'lifetime' => 0,
    'path' => '/',
    'domain' => '',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Lax'
]);

session_start();

The appropriate SameSite value depends on the application's navigation, federation, embedded-content and cross-site requirements.

PHP Login Session Example

<?php

declare(strict_types=1);

require_once 'session_bootstrap.php';

function authenticateUser(
    string $username,
    string $password
): ?array {
    /*
     * Replace with a parameterized database query
     * and password_verify() against a securely
     * stored password hash.
     */

    return null;
}

if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    http_response_code(405);

    exit(
        'Method not allowed.'
    );
}

$username =
    trim(
        $_POST['username'] ?? ''
    );

$password =
    $_POST['password'] ?? '';

$user =
    authenticateUser(
        $username,
        $password
    );

if ($user === null) {
    http_response_code(401);

    exit(
        'Invalid credentials.'
    );
}

if (!session_regenerate_id(true)) {
    http_response_code(500);

    exit(
        'Unable to establish session.'
    );
}

$_SESSION['user_id'] =
    (int)$user['id'];

$_SESSION['authenticated_at'] =
    time();

$_SESSION['last_activity_at'] =
    time();

http_response_code(204);

The session identifier is regenerated after authentication so the authenticated session does not retain a pre-authentication identifier.

Validate a PHP Session

<?php

declare(strict_types=1);

require_once 'session_bootstrap.php';

const IDLE_TIMEOUT_SECONDS = 1800;
const ABSOLUTE_TIMEOUT_SECONDS = 28800;

function revokeCurrentSession(): void
{
    $_SESSION = [];

    if (ini_get(
            'session.use_cookies'
        )) {

        $parameters =
            session_get_cookie_params();

        setcookie(
            session_name(),
            '',
            [
                'expires' => time() - 3600,
                'path' => $parameters['path'],
                'domain' => $parameters['domain'],
                'secure' => $parameters['secure'],
                'httponly' => $parameters['httponly'],
                'samesite' => $parameters['samesite']
            ]
        );
    }

    session_destroy();
}

$userId =
    $_SESSION['user_id'] ?? null;

$authenticatedAt =
    $_SESSION['authenticated_at'] ?? null;

$lastActivityAt =
    $_SESSION['last_activity_at'] ?? null;

if (!is_int($userId) ||
    !is_int($authenticatedAt) ||
    !is_int($lastActivityAt)) {

    revokeCurrentSession();

    http_response_code(401);

    exit(
        'Authentication required.'
    );
}

$currentTime =
    time();

$idleExpired =
    $currentTime - $lastActivityAt
    > IDLE_TIMEOUT_SECONDS;

$absoluteExpired =
    $currentTime - $authenticatedAt
    > ABSOLUTE_TIMEOUT_SECONDS;

if ($idleExpired ||
    $absoluteExpired) {

    revokeCurrentSession();

    http_response_code(401);

    exit(
        'Session expired.'
    );
}

$_SESSION['last_activity_at'] =
    $currentTime;

The timeout values are illustrative. Production values must follow the application's security, usability and organizational requirements.

PHP Logout Example

<?php

declare(strict_types=1);

require_once 'session_bootstrap.php';

$_SESSION = [];

if (ini_get(
        'session.use_cookies'
    )) {

    $parameters =
        session_get_cookie_params();

    setcookie(
        session_name(),
        '',
        [
            'expires' => time() - 3600,
            'path' => $parameters['path'],
            'domain' => $parameters['domain'],
            'secure' => $parameters['secure'],
            'httponly' => $parameters['httponly'],
            'samesite' => $parameters['samesite']
        ]
    );
}

session_destroy();

http_response_code(204);

A distributed server-side session implementation must also invalidate the corresponding session record in the shared session store.

Example Session Table

CREATE TABLE user_sessions
(
    session_id_hash CHAR(64) PRIMARY KEY,
    user_id BIGINT NOT NULL,
    created_at DATETIME NOT NULL,
    last_activity_at DATETIME NOT NULL,
    expires_at DATETIME NOT NULL,
    revoked_at DATETIME NULL,
    authentication_level VARCHAR(30) NOT NULL,
    INDEX ix_user_sessions_user_id (user_id),
    INDEX ix_user_sessions_expires_at (expires_at)
);

This is an illustrative structure. The final schema should reflect the selected database, token-hashing method, retention policy, query patterns and privacy requirements.

Session Cleanup

Expired and revoked session records should be removed or archived according to an explicit retention policy.

DELETE FROM user_sessions
WHERE
    expires_at < CURRENT_TIMESTAMP
    OR revoked_at IS NOT NULL;

Cleanup can run through a controlled scheduled process. Large deletes may require batching to avoid extended locking, log growth or load spikes.

Sensitive Operations

A valid session does not always provide sufficient assurance for every action.

Sensitive actions can require:

• Recent reauthentication
• Multi-factor authentication
• Transaction confirmation
• Current authorization evaluation
• CSRF validation
• Risk-based controls
• Audit logging

Valid session
      |
      v
Sensitive operation requested
      |
      v
Check recent authentication
      |
      +--> Sufficient:
      |       continue authorization
      |
      +--> Insufficient:
              require step-up authentication

Privacy Considerations

Cookies can be used for necessary application functions or for tracking user activity.

Privacy-aware design should include:

• Collecting only necessary data
• Using clear cookie purposes
• Applying appropriate retention periods
• Avoiding sensitive personal data in cookie values
• Restricting third-party sharing
• Providing required notice and controls
• Following applicable organizational and legal requirements

Important Session Metrics

Inspect Cookies with curl

Save Received Cookies

curl -c cookies.txt -i https://example.com/login

Send Stored Cookies

curl -b cookies.txt -i https://example.com/dashboard

Verbose Cookie Exchange

curl -v -c cookies.txt -b cookies.txt https://example.com/

Cookie files can contain authentication credentials. Store and handle them only in approved test environments, restrict access and remove them after use.

Browser Inspection

Browser developer tools can help inspect:

• Cookies stored for the current site
• Cookie domain and path
• Secure and HttpOnly status
• SameSite policy
• Expiration
• Set-Cookie response fields
• Cookie request fields
• Blocked-cookie reasons

Troubleshooting Workflow

1. Confirm the exact hostname, scheme and request path.
2. Inspect the server's Set-Cookie response.
3. Verify that the browser accepted and stored the cookie.
4. Inspect Domain, Path, Secure, HttpOnly and SameSite attributes.
5. Verify that the cookie is included in the expected later request.
6. Check whether the session record exists.
7. Check idle, absolute and event-driven expiration.
8. Check whether the session ID was rotated unexpectedly.
9. Inspect proxy and load-balancer behaviour.
10. Verify authorization after successful session validation.
11. Check server clock consistency.
12. Compare the failing browser flow with a working request.

Scenario: Cookie Is Stored but Not Sent

Investigate:

• Request scheme and the Secure attribute
• Request hostname and cookie domain
• Request path and cookie path
• SameSite policy and request context
• Cookie expiration
• Browser privacy policy
• Cross-origin request credentials configuration
• Whether the cookie was replaced by another cookie with the same name

Scenario: User Is Logged Out Unexpectedly

Investigate:

• Idle-session expiration
• Absolute-session expiration
• Session-store eviction
• Application restart with memory-only sessions
• Load balancing across instances without shared state
• Cookie expiration or rejection
• Session identifier regeneration
• Password or account-security events
• Server clock differences

Scenario: Login Redirect Loop

Request protected page
        |
        v
Application finds no valid session
        |
        v
Redirect to login
        |
        v
Login succeeds and sets cookie
        |
        v
Redirect to protected page
        |
        v
Cookie is missing or session cannot be loaded
        |
        v
Redirect to login again

Investigate:

• Whether Set-Cookie was returned
• Whether the browser accepted the cookie
• Domain and path mismatch
• Secure cookie used over an insecure request
• SameSite behaviour during an external identity flow
• Session-store consistency
• Proxy hostname and scheme forwarding
• Redirect target hostname changes

Common Cookies and Sessions Mistakes

Recommended Test Cases

Cookies and Sessions Best Practices

Practice Exercise

Build and test a secure server-side login session for a PHP web application.

Requirements

1. Require HTTPS for authenticated pages.
2. Generate the session identifier through PHP's secure session mechanism.
3. Use Secure, HttpOnly and an intentional SameSite policy.
4. Regenerate the identifier after successful login.
5. Store only the required authenticated state in the session.
6. Apply an idle timeout.
7. Apply an absolute timeout.
8. Protect state-changing forms with anti-CSRF validation.
9. Authorize every protected operation.
10. Invalidate the server-side session during logout.
11. Remove the browser cookie during logout.
12. Reject an old identifier after rotation or logout.
13. Redact session identifiers from logs.
14. Test behaviour across several application instances.

Session Design Template

Cookie name:
<Application-specific name>

Cookie scope:
<Host and path>

Secure:
<Required>

HttpOnly:
<Required when script access is unnecessary>

SameSite:
<Strict, Lax or None with justification>

Session identifier:
<Opaque cryptographically secure random value>

Server-side store:
<Database, distributed cache or dedicated service>

Idle timeout:
<Policy-defined duration>

Absolute timeout:
<Policy-defined duration>

Rotation events:
<Login, privilege change, reauthentication and others>

Revocation events:
<Logout, password reset, account disablement and others>

CSRF protection:
<Token, origin validation and SameSite policy>

Authorization:
<Per-operation access evaluation>

Monitoring:
<Failures, expiration, revocation and store health>

Frequently Asked Questions