Cookie SecurityLevel 2 — IntermediateMedium severity

Cookie Security: Are Cookies Configured Safely?

Using browser DevTools to check whether cookies have the Secure, HttpOnly, and SameSite attributes set.

Tools required: browser DevTools

Overview

A cookie missing Secure or HttpOnly isn't visible to a normal user at all - it's a silent risk. This guide shows exactly where to look in the browser to check every cookie a site sets.

Step-by-Step Manual Check

1

Open the cookie inspector

OSI Layer 7

Every cookie a site has set for the current visit is listed here, along with its attributes as a set of columns.

Browser DevTools · cross-platform
Chrome/Edge: F12 > Application tab > Storage > Cookies > select the domain. Firefox: F12 > Storage tab > Cookies.

Healthy result

A table listing every cookie name, value, domain, and a set of attribute columns (Secure, HttpOnly, SameSite).

Problem result

No cookies listed at all for a site that should be setting a session cookie (e.g. after logging in).

What it means

If a session cookie is completely absent after what should have set one, the problem isn't cookie security - it's that the cookie isn't being set at all, which points to a server-side session/login bug rather than this guide's scope.

If unresolved, escalate to: Level 1 — Basic

2

Check the Secure and HttpOnly columns

OSI Layer 7

These two attributes are the baseline protection every session or authentication cookie should have.

Browser DevTools · cross-platform
In the cookie table, read the Secure and HttpOnly columns for each cookie (shown as a checkmark or true/false).

Healthy result

Session/authentication cookies show checked (true) for both Secure and HttpOnly.

Problem result

A session or authentication cookie shows unchecked (false) for Secure or HttpOnly.

What it means

Missing Secure means the cookie could be sent over a plain HTTP connection if one ever happens (e.g. a mixed-content bug or an old HTTP link), exposing it in transit. Missing HttpOnly means client-side JavaScript can read the cookie - if the site has any XSS vulnerability elsewhere, that bug can now be used to steal the session directly.

If unresolved, escalate to: Level 2 — Intermediate

3

Check the SameSite attribute

OSI Layer 7

SameSite controls whether the cookie is sent on cross-site requests, which is the primary defense against CSRF (cross-site request forgery).

Browser DevTools · cross-platform
In the same cookie table, read the SameSite column.

Healthy result

Lax or Strict for session/auth cookies.

Problem result

None (with Secure not set), or the column is blank/empty.

What it means

SameSite=None is only legitimate when the cookie must be sent across sites on purpose (e.g. an embedded payment widget), and modern browsers require Secure to be set alongside it or they reject the cookie outright. A blank SameSite value defaults to Lax in current browsers, but explicit is better than relying on the default.

If unresolved, escalate to: Level 2 — Intermediate

4

Cross-check headlessly with curl (no browser needed)

OSI Layer 7

Useful when checking from a server, CI pipeline, or anywhere without a graphical browser available.

curl · cross-platform
curl -v https://example.com/login 2>&1 | grep -i "set-cookie"

Healthy result

set-cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

Problem result

set-cookie: session=abc123
(no attributes listed after the value at all)

What it means

This is the exact raw instruction the server sent - if Secure/HttpOnly/SameSite aren't in this line, they were never set server-side, confirming the finding independent of any specific browser's rendering of it.

If unresolved, escalate to: Level 2 — Intermediate

Interpreting the Results

Cookie issues are invisible to a typical visitor - the site looks and works completely normally either way. That's exactly why they need a deliberate check rather than being caught by casual use; treat any session/auth cookie missing Secure or HttpOnly as worth fixing regardless of whether anything has gone wrong yet.

Common Causes

SymptomLikely CauseFix
Session cookie missing SecureFramework default doesn't set Secure automatically, or the app was originally built for local HTTP development and never updatedSet the Secure flag explicitly in the application's session/cookie configuration for production.
Cookie missing HttpOnlyCookie is deliberately readable by client-side JavaScript for a legitimate reason (e.g. a UI preference), or it was simply never configuredAdd HttpOnly to any cookie that doesn't need JavaScript access - especially session/auth cookies.
SameSite=None without SecureCross-site embedding requirement was implemented without updating the Secure flag alongside itAdd Secure whenever SameSite=None is used - modern browsers reject the combination otherwise.

Automated by

Diagnostic Suite - Site Latency Diagnostic (Option 2)

Automatically inspects every cookie set by the site and flags missing Secure/HttpOnly/SameSite attributes.