cookies

Overview

HTTP is stateless — each request stands alone and the server does not inherently remember the last one. Cookies are the standard way applications add memory across requests: small values the server asks the browser to store and send back every time. In HTTP challenges, cookies are frequently where the interesting state lives — a session, a role flag, or a value the developer trusted. This lesson explains how cookies work and why they are a common challenge target, practiced against authorized labs only.

Learning objectives

• Explain how cookies give stateful behavior to a stateless protocol.
• Describe how Set-Cookie and the Cookie header work together.
• Recognize the security attributes of cookies and why a poorly designed cookie is a challenge target.

Core concept

A cookie is a small named value stored by the browser on behalf of a site. The server sends a Set-Cookie response header telling the browser to store it; the browser then includes it in the Cookie header on every subsequent request to that site. This is how a server recognizes that many separate requests belong to the same session or user. Because the cookie travels on each request and the client stores it, the design of a cookie — what it contains and how it is protected — determines whether it can be tampered with.

How it works

1. The server responds with, for example, Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax.
2. The browser stores session=abc123.
3. On every later request to that site, the browser automatically sends Cookie: session=abc123.
4. The server reads that value to look up who you are or what state you are in.

Cookies carry attributes that control their safety:

• HttpOnly — The cookie cannot be read by page JavaScript, reducing theft via cross-site scripting.
• Secure — The cookie is only sent over HTTPS.
• SameSite — Restricts whether the cookie is sent on cross-site requests, mitigating cross-site request forgery.
• Expires / Max-Age — How long the cookie lives.
• Domain / Path — Which requests the cookie is attached to.

A well-designed session cookie holds an opaque, unguessable identifier that maps to state stored safely on the server. A poorly designed one holds meaningful, unprotected data — like role=user or admin=false — which the client can simply edit.

Practical example

In an isolated challenge you log in and inspect your cookies. Alongside a session cookie you find role=guest. Because that value is meaningful and not cryptographically protected, you change it to role=admin in your request and resend it. The application, which trusted the cookie's contents instead of verifying state on the server, now treats you as an administrator and shows the flag. The lesson is not "cookies are bad" — it is that trusting client-editable data in a cookie is the flaw. A cookie holding an opaque session ID could not be tampered with this way.

Cybersecurity relevance

Cookies are central to web authentication, so they are central to web security. Common real-world issues that challenges mirror include: putting sensitive or authorization data directly in a cookie where the client can edit it, missing HttpOnly/Secure/SameSite attributes, predictable session identifiers, and failing to invalidate sessions. Testers examine cookies early on an authorized target — reading their contents, checking their attributes, and testing whether tampering changes behavior. Defenders use opaque session IDs, set protective attributes, and verify authorization on the server for every request rather than trusting the cookie's payload.

Common mistakes

• Storing meaningful, unprotected data in a cookie (like role=admin) and trusting it server-side.
• Omitting security attributes (HttpOnly, Secure, SameSite), leaving cookies exposed to theft or cross-site abuse.
• Assuming cookies are hidden from the user — they are stored client-side and can be read and edited.

Key takeaways

• Cookies add state to stateless HTTP: the server sends Set-Cookie, and the browser returns the value in the Cookie header on every later request.
• Attributes like HttpOnly, Secure, and SameSite protect cookies; a good session cookie is an opaque, unguessable identifier mapped to server-side state.
• Cookies whose contents are meaningful and unprotected can be edited by the client, which is why cookie tampering is a frequent HTTP-challenge technique.

Check your understanding

• Why can a cookie containing role=guest be a vulnerability, while a cookie containing an opaque random session ID is not tampering-prone?
• What do the HttpOnly and Secure cookie attributes each protect against?