How HTTP Cookies Work: Session Management and Security

Short answer

An HTTP cookie is a small piece of data a server sends to a browser, which the browser stores and sends back on every subsequent request to the same domain. Cookies are how the web remembers who you are between page loads — and they are the most common target for session theft.

The idea in one minute

Imagine a coffee shop that gives each customer a numbered token when they place an order. You hand over your token when you return to pick up your drink. The token itself is meaningless, but it lets the barista find your order without you repeating your name and payment details.

When you log in to a website, the server creates a session record and gives your browser a cookie containing a random session ID. On every subsequent request, your browser presents that cookie. If someone steals your token, they can pick up your order. Cookie theft works the same way — an attacker who steals your session cookie can impersonate you without knowing your password.

How cookies are set and sent

The server sets a cookie via the Set-Cookie response header: Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax. The browser stores it per-domain — nyxeara.vip cookies are never sent to evil.com. On every subsequent request to the same domain, the browser attaches matching cookies in the Cookie header: Cookie: sessionId=abc123. The server reads this header, looks up the session, and serves the authenticated page.

The request flow

Three steps: (1) server sends Set-Cookie in the HTTP response, (2) browser stores the cookie keyed by domain, (3) browser automatically attaches the cookie via the Cookie header on every subsequent request to that domain. The server never explicitly requests the cookie — the browser decides when to send it based on domain, path, and the cookie's attributes.

A minimal example

from flask import Flask, make_response
app = Flask(__name__)

@app.route("/login")
def login():
    resp = make_response("Logged in")
    resp.set_cookie("sessionId", "abc123",
                    httponly=True, secure=True,
                    samesite="Lax", max_age=3600)
    return resp

The resulting header: Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Max-Age=3600; Path=/.

Why cookies are trust-bearing tokens

A cookie is a bearer token: whoever presents it is treated as the authenticated user. The server has no way to distinguish between the legitimate user sending their own cookie and an attacker replaying a stolen one. This is why cookie attributes exist — they are not configuration preferences but security controls that reduce the attack surface. A cookie without Secure can be stolen from network traffic. A cookie without HttpOnly can be stolen by any XSS. A cookie without SameSite can be used by CSRF.

What attackers look for

Any Set-Cookie header lacking Secure, HttpOnly, or SameSite. Overly broad Domain attributes that extend the cookie's scope to subdomains the attacker might control. Session cookies with long Max-Age values (weeks or years) that remain valid even after the user has stopped using the site. Cookies set before an HTTP-to-HTTPS redirect, which exposes them in cleartext.

Detection

Inspect every Set-Cookie header across the application. Check for Secure, HttpOnly, and SameSite on every authentication cookie. Visit the site over HTTP and check whether cookies are set before the redirect — if so, they were transmitted in cleartext. Type document.cookie in the browser console — if session cookies appear, they lack HttpOnly.

Verification: real vulnerability or false positive?

Confirm the cookie without Secure is an authentication cookie (not a tracking cookie). Check whether the site actually listens on HTTP — a cookie missing Secure on an HTTPS-only site may not be directly exploitable. Test SameSite behavior in real browsers (Chrome 80+ defaults to Lax). Verify the Domain scope: Domain=.com or an overly broad TLD is a vulnerability; Domain matching the exact origin is standard.

Real-world impact

A session cookie without Secure can be sniffed over public Wi-Fi with tcpdump — immediate account takeover with no additional exploit. Without HttpOnly, a single stored XSS on any page of the domain leaks every user's session cookie. Without SameSite, a CSRF attack can perform state-changing actions (funds transfer, email change) using the victim's cookies. A cookie with an overly broad Domain lets a compromised subdomain impersonate the parent domain's sessions.

Prevention

Set Secure and HttpOnly on every authentication cookie. Set SameSite=Lax or Strict. Omit Domain to restrict to the exact origin. Use the __Host- prefix so the browser enforces origin-scoping and Secure automatically. Set short Max-Age (hours, not weeks). Invalidate sessions server-side on logout.

Related vulnerabilities

CSRF — attacker tricks browser into sending cookie-authenticated request cross-origin
XSS — steals cookies via document.cookie unless HttpOnly is set
Session fixation — attacker sets a known session ID before the victim authenticates
Clickjacking — combined with cookie-based auth to perform actions without user knowledge

Testing methodology (do this safely)

Inspect cookies in browser DevTools (Application > Cookies) for Secure, HttpOnly, SameSite, and Domain. Test for CSRF by submitting a cross-origin form and checking whether cookies attach. Verify server-side session invalidation on logout. Test only on your own applications or authorized targets.

Nyxeara perspective

Cookie misconfigurations are among the most frequent findings in web audits, but they are almost never exploitable in isolation — a missing HttpOnly is harmless until an XSS is found. The Nyxeara engine flags cookie attributes as part of a dependency graph: a missing HttpOnly is elevated in severity when combined with a DOM-based XSS finding on the same origin. A cookie without Secure on a page with mixed content warnings is a real attack chain, not a configuration note.