Cookies Explained: First-Party, Third-Party, SameSite and the Flags That Protect Them

A cookie is a small name-value pair a website asks your browser to store and return on later requests, which is how you stay logged in. It becomes a tracking tool when a third party embedded on many sites sets the same cookie everywhere. The Secure, HttpOnly and SameSite attributes decide whether that cookie can be stolen over HTTP, read by scripts or sent on cross-site requests.

What a cookie is, mechanically

HTTP has no memory. Every request stands alone, so a server needs some way to recognise that the request for page two comes from the person who logged in on page one. The cookie, defined in RFC 6265, is that mechanism. The server includes a Set-Cookie header in a response; the browser stores the name, value and attributes; on every subsequent request to a matching host and path, the browser sends the name and value back in a Cookie header. That is all. A cookie cannot run code, read your files or see other sites' cookies.

HTTP/1.1 200 OK
Set-Cookie: __Host-session=9f3a1c…; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: theme=dark; Path=/; Max-Age=31536000; Secure; SameSite=Lax

GET /account HTTP/1.1
Host: example.com
Cookie: __Host-session=9f3a1c…; theme=dark

The first cookie is the important one. Its value is a random session identifier that the server maps to your logged-in account, and anyone who obtains that value is, to the server, you. Everything in cookie security is about protecting values like that one.

First-party and third-party are about context

People talk about first-party and third-party cookies as if they were two kinds of cookie. They are the same kind. The difference is the context in which the browser sends them. When you visit news.example and its own server sets a cookie, that is a first-party cookie in that context. If news.example embeds a script, image or iframe from ads.example, and ads.example sets a cookie, that cookie is third-party in this context. Visit shop.example tomorrow, which embeds the same ads.example pixel, and the browser sends the same cookie back. The ad network now knows that one person read that article and looked at that product. Multiply by every site that embeds the pixel and you have the profile-building described in how online tracking works.

This is why browsers treat the two contexts so differently. Browsers have spent a decade deciding what to do about the third-party case, and as of 2026 the answers diverge sharply.

The practical consequence for a Chrome or Edge user is that one setting change moves you from the most permissive posture of the four to roughly Safari's. The browser check reports the observable result as third-party cookies allowed, which is more reliable than reading the settings page, because extensions and enterprise policies can override it.

The attributes that protect a cookie

Three attributes on Set-Cookie decide how well a session cookie survives contact with an attacker. They are set by the site, not by you, so this section is partly about judging sites and partly about understanding what your browser enforces.

Secure

A cookie with the Secure attribute is only ever sent over HTTPS. Without it, the browser will attach the cookie to a plain HTTP request to the same host, and anyone on the network path can read it. A site that redirects HTTP to HTTPS is not enough on its own, because the cookie is sent on the first, unencrypted request before the redirect arrives. Our website scanner reports the omission as cookie without Secure flag.

HttpOnly

A cookie with HttpOnly is invisible to JavaScript: document.cookie does not include it. This does not stop cross-site scripting, but it stops the most valuable payoff of cross-site scripting, which is reading the session cookie and sending it to the attacker. A session cookie without it is reported as cookie without HttpOnly flag. There is no reason for a session cookie to be readable by script, so treat its absence as carelessness.

SameSite

SameSite controls whether the cookie is sent on requests that originate from a different site. It has three values. Strict never sends the cookie on a cross-site request, even a plain link click, which is very safe and mildly annoying because arriving from a link in an email lands you logged out. Lax sends the cookie on top-level navigations that use safe methods such as a link click, but not on embedded loads or cross-site form posts, which is the default behaviour Chrome adopted in 2020 for cookies that do not specify a value, and Firefox and Edge follow. None sends it always, and is only permitted together with Secure. SameSite is the browser-side defence against cross-site request forgery; a cookie with no value is reported as cookie without SameSite attribute, and whether your own browser applies the Lax default is tested as SameSite default enforcement.

Cookie prefixes

A cookie whose name begins with __Host- is accepted by the browser only if it has Secure, has Path=/ and has no Domain attribute, which means it can only be set by the exact host over HTTPS and cannot be overwritten by a subdomain. __Secure- requires only the Secure attribute. These prefixes let a site tell the browser to enforce the rules rather than merely request them. The server-side detail for all of these is in cookie security flags.

How long cookies live

A cookie with no Expires or Max-Age is a session cookie in the original sense: it is meant to be discarded when the browser closes. In practice, browsers that restore tabs on restart also restore session cookies, so "closes" is fuzzier than it sounds. A cookie with an expiry can live for years, and tracking cookies routinely ask for the maximum the browser allows. Safari caps script-set cookies at seven days and, in some circumstances, 24 hours; Chrome caps Expires at 400 days. Long-lived identifiers are what make cross-site tracking work, which is why deleting cookies on a schedule, as described in automatically deleting cookies, cuts tracking so effectively without breaking the sites you use every day.

Controlling cookies as a user

1. Block or partition third-party cookies. Already true in Firefox and Safari; one setting in Chrome and Edge, as in the table above.
2. Do not block all cookies. Every login on the web depends on first-party cookies. Blocking them entirely is the setting most often reversed within a day.
3. Delete cookies for sites you do not want to remember you. All four browsers let you clear data for a single site from the site information panel next to the address bar, and let you set a list of sites whose cookies are cleared on exit.
4. Use a private window for one-off visits. Its cookie jar is discarded when the last private window closes.
5. Do not treat cookie deletion as anonymity. Your IP address and fingerprint are untouched, which is the whole reason trackers moved to fingerprinting.

There is also a newer mechanism worth knowing about: the Partitioned attribute (CHIPS) lets a third party set a cookie that the browser keys to the top-level site, so an embedded chat widget can keep its own state on each site without that state being shared across sites. It is Chrome's, and increasingly Firefox's, way of letting legitimate embedded services work under third-party blocking, and it is a good sign when a widget uses it.

Cookies are the oldest and most transparent of the tracking mechanisms; the newer ones are covered from the browser's side in the browser security hub and the full set of per-browser toggles is in browser security settings.