Web Cookie Security and Auditing: A Complete Guide

How HTTP Cookies Work

HTTP is a stateless protocol — each request from a browser to a server is independent, carrying no memory of previous interactions. Cookies are the mechanism that adds state to this stateless protocol. When a server wants the browser to remember something (a session identifier, a user preference, a consent choice), it includes a Set-Cookie header in its HTTP response. The browser stores the cookie and automatically includes it in subsequent requests to the same domain via the Cookie request header.

A cookie is fundamentally a key-value pair: a name and a value. The value can contain any text data, though it is typically a session token, a user ID, or a serialized data structure. Beyond the name and value, the Set-Cookie header supports several attributes that control the cookie's scope, lifetime, and security properties. These attributes are the focus of this guide, because misconfiguring them is the root cause of most cookie-related security and compliance issues.

In the ad tech ecosystem, cookies serve multiple functions: tracking user sessions across publisher sites, storing consent signals (like TCF strings), maintaining frequency caps for ad campaigns, enabling cross-domain user identification for retargeting, and persisting authentication tokens for platform logins. Each use case demands specific attribute configurations, and getting them wrong can compromise security, break functionality, or violate privacy regulations.

Set-Cookie Header Attributes Explained

Each attribute in the Set-Cookie header controls a specific aspect of how the browser handles the cookie. Understanding every attribute is essential for both security auditing and debugging.

Domain

The Domain attribute specifies which hosts the cookie should be sent to. If set to Domain=example.com, the cookie is sent with requests to example.com and all of its subdomains (www.example.com, api.example.com, etc.). If the Domain attribute is omitted, the cookie is scoped to the exact host that set it — no subdomains are included. This distinction matters for ad tech: a tracking cookie that needs to work across ads.example.com and pixel.example.com must set an explicit Domain value. A cookie scoped too broadly (to a parent domain shared with untrusted subdomains) creates a security risk.

Path

The Path attribute restricts the cookie to a specific URL path and its subdirectories. A cookie with Path=/admin is only sent with requests to URLs that start with /admin. The default path is the directory of the URL that set the cookie. In practice, most ad tech cookies use Path=/ to ensure the cookie is available across the entire site, but path scoping can be useful for isolating session cookies to specific application sections.

Expires and Max-Age

These attributes control the cookie's lifetime. Expires sets an absolute expiration date and time (in HTTP date format). Max-Age sets the cookie's lifetime in seconds from the current moment. If both are present, Max-Age takes precedence in modern browsers. If neither is set, the cookie becomes a "session cookie" that is deleted when the browser closes. For ad tech, persistent cookies (those with an expiration date) are used for cross-session tracking and frequency capping, while session cookies are appropriate for authentication tokens that should not survive browser restarts.

Secure

The Secure flag instructs the browser to only send the cookie over HTTPS connections. Without this flag, the cookie can be transmitted over unencrypted HTTP, where it is vulnerable to interception by network attackers. Every cookie that contains a session token, user identifier, or any sensitive data should have the Secure flag set. In modern ad tech, where virtually all traffic is HTTPS, there is no valid reason to omit this flag on any cookie.

HttpOnly

The HttpOnly flag prevents the cookie from being accessed via JavaScript (document.cookie). This protects the cookie from cross-site scripting (XSS) attacks — even if an attacker injects malicious JavaScript into a page, they cannot read HttpOnly cookies. Session tokens and authentication cookies should always be HttpOnly. However, cookies that need to be read by client-side scripts (such as consent strings accessed by the CMP's JavaScript) cannot use this flag, which is a necessary tradeoff.

SameSite

The SameSite attribute controls whether the cookie is sent with cross-site requests. It has three possible values — Strict, Lax, and None — each providing a different level of cross-site access. Because of its complexity and its critical importance to ad tech, SameSite is covered in its own section below.

Using the Cookie Inspector Tool

The Cookie Inspector parses raw Set-Cookie and Cookie headers, extracts every attribute, and highlights security and compliance issues. Here is a step-by-step walkthrough:

1. Paste your headers. Copy Set-Cookie headers from your browser's developer tools (Network tab → select a request → look in the Response Headers section) or from server-side logs. You can paste one header or multiple headers, each on its own line.
2. Click Analyze. The tool parses each cookie, extracting the name, value, and every attribute. It identifies missing attributes and flags potential issues automatically.
3. Review the findings. Each cookie is displayed with its attributes and a list of warnings. Warnings include missing Secure flag, missing HttpOnly, SameSite=None without Secure, missing expiration, overly broad domain scope, and other security concerns. The severity of each warning is indicated so you can prioritize remediation.

SameSite in Depth

The SameSite attribute is the most consequential cookie setting for ad tech. It determines whether the browser sends the cookie when the request originates from a different site than the one that set the cookie — which is exactly what happens with cross-domain tracking pixels, ad server requests, and programmatic auction calls.

SameSite=Strict

With Strict, the cookie is never sent on cross-site requests. If a user is on publisher.com and the page makes a request to adserver.com, a Strict cookie set by adserver.com will not be included. This is the most secure setting but is incompatible with cross-site ad tech use cases. It is appropriate for session cookies on a single-domain application where cross-site access is never needed.

SameSite=Lax

With Lax, the cookie is sent on cross-site top-level navigations (clicking a link from one site to another) but not on cross-site sub-requests (images, iframes, AJAX calls, tracking pixels). This is now the browser default when no SameSite value is specified. For ad tech, Lax means that tracking pixels and programmatic bid requests will not receive the cookie, which breaks most cross-domain identification workflows. However, click-through URLs (where the user navigates to the advertiser's site) will receive the cookie.

SameSite=None

With None, the cookie is sent on all cross-site requests, just like the pre-SameSite behavior. This is the setting required for cross-domain ad tech cookies — tracking pixels, auction calls, and third-party identifiers all need SameSite=None to function. However, browsers enforce a critical requirement: any cookie with SameSite=None must also have the Secure flag. If Secure is missing, the browser silently rejects the cookie. This is one of the most common cookie issues in ad tech and the Cookie Inspector flags it automatically.

Third-Party Cookie Deprecation

The ad tech industry is navigating a fundamental shift as major browsers restrict or eliminate third-party cookies. Safari (via Intelligent Tracking Prevention) and Firefox (via Enhanced Tracking Protection) already block third-party cookies by default. Chrome has announced plans to phase out third-party cookies and has introduced the Privacy Sandbox APIs as replacement mechanisms.

For cookie auditing, this means that cookies set by domains different from the page's domain may not be stored or sent by certain browsers, regardless of their SameSite setting. When auditing cookies, it is important to test in multiple browsers to understand actual cookie behavior. A cookie that works perfectly in Chrome today may already be blocked in Safari. The Cookie Inspector helps identify which cookies are third-party (set by a domain different from the page domain) so you can assess the impact of deprecation on your workflows.

Common Security Issues and Remediations

The following security issues are frequently discovered during cookie audits. Each issue includes the risk it creates and the recommended fix.

1. Missing Secure Flag

Risk: The cookie can be transmitted over unencrypted HTTP connections, allowing network attackers to intercept it. Fix: Add Secure to every cookie that contains sensitive data. In practice, add it to all cookies — there is no downside on HTTPS-only sites.

2. Missing HttpOnly Flag on Session Cookies

Risk: An XSS vulnerability allows attackers to steal session tokens via document.cookie. Fix: Add HttpOnly to all session and authentication cookies. Only omit it for cookies that must be read by client-side JavaScript (and document why).

3. SameSite=None Without Secure

Risk: The cookie is silently rejected by all modern browsers, breaking cross-site functionality without any visible error message. Fix: Always pair SameSite=None with Secure. The Cookie Inspector automatically flags this combination.

4. Overly Broad Domain Scope

Risk: A cookie scoped to a parent domain (like .example.com) is accessible to all subdomains, including those that may be controlled by different teams or contain user-generated content. A compromised or malicious subdomain can read and exfiltrate the cookie. Fix: Scope cookies to the most specific domain that needs access. Omit the Domain attribute to restrict the cookie to the exact setting host.

5. Excessive Cookie Lifetime

Risk: A cookie with an expiration date years in the future persists far longer than necessary, increasing the window during which a stolen cookie remains valid. Fix: Set expiration times appropriate to the cookie's purpose. Session tokens should be short-lived (hours to days). Preference cookies can be longer (weeks to months). Tracking cookies should align with your data retention policy.

6. Sensitive Data in Cookie Value

Risk: Storing plaintext emails, names, or other personal data in a cookie value exposes that data to anyone who can access the cookie — through XSS, network interception, or browser extensions. Fix: Store only opaque identifiers (session tokens, hashed IDs) in cookies. Keep the sensitive data on the server, keyed by the identifier.

7. Missing SameSite Attribute

Risk: Browsers default to Lax when SameSite is not specified, which may break expected cross-site cookie behavior. Fix: Always explicitly set the SameSite attribute. For cross-site cookies, set SameSite=None; Secure. For same-site cookies, set SameSite=Lax or SameSite=Strict.

Auditing Cookies for Compliance

Privacy regulations such as GDPR and ePrivacy require organizations to document and justify every cookie they set. A cookie audit involves inventorying all cookies, classifying them by purpose (strictly necessary, functional, analytics, advertising), verifying that non-essential cookies are only set after obtaining consent, and ensuring that cookie attributes align with security best practices.

To conduct a thorough audit, visit your site in a clean browser profile (no cached cookies), interact with the consent dialog, and then export all Set-Cookie headers from the Network tab. Paste them into the Cookie Inspector to analyze each cookie's attributes. Document which cookies are set before consent is given (these must be strictly necessary) and which appear only after consent (these are the ones governed by the user's consent choices).

Generating Audit Reports

After analyzing your cookies, compile the findings into an audit report that can be shared with your legal, privacy, and engineering teams. A good audit report includes a table of all cookies with their name, domain, path, lifetime, attributes, and classification. It should list all security warnings with severity ratings, identify any cookies that are set without consent when they should require it, and recommend specific remediation steps for each issue found.

The Cookie Inspector's structured output can serve as the foundation for this report. Copy the analysis results, add your compliance classifications and business context, and distribute to stakeholders. Repeat the audit on a regular schedule — quarterly is a common cadence — to catch new cookies introduced by code changes, third-party scripts, or updated vendor integrations.