You don't have javascript enabled. Please enable javascript to use this website.

Secure Cookie Test
Parses Set-Cookie response headers from any domain to show the Secure, HttpOnly, and SameSite security attributes on each cookie.
More Tools
HTTP Header Checker — View All Response Headers SSL Certificate Checker HTTP/2 Support Test Brotli Compression Test

Secure Cookie Test — What It Checks and Why It Matters

Secure Cookie Test sends a live GET request to any domain and parses the Set-Cookie response headers for the three security attributes defined in RFC 6265: the Secure flag, the HttpOnly flag, and the SameSite attribute. Each cookie found is analyzed individually. A cookie missing any of these attributes is a potential attack vector — Secure prevents HTTPS bypass, HttpOnly blocks XSS-based theft, and SameSite mitigates CSRF.

What Each Cookie Security Attribute Means

HTTP cookies are defined in RFC 6265. The Set-Cookie response header carries the cookie value and its attributes. Three attributes control security:

Diagram of cookie flags: Secure only over HTTPS stops snooping, HttpOnly hidden from JavaScript stops XSS theft, SameSite stops cross-site request forgery
Three flags, three attacks blocked.
Attribute What It Does Attack Mitigated Default if Absent
Secure Cookie sent over HTTPS only — never over unencrypted HTTP Network interception (man-in-the-middle) Cookie sent on HTTP and HTTPS
HttpOnly Cookie hidden from JavaScript — not accessible via document.cookie XSS-based session token theft Cookie readable by client-side scripts
SameSite=Strict Cookie never sent on cross-site requests CSRF — strongest protection —
SameSite=Lax Cookie sent on top-level navigations, blocked on subresource requests Most CSRF — recommended default —
SameSite=None Cookie sent on all cross-site requests — requires Secure flag None — use only for legitimate cross-site flows —
SameSite absent — Partial CSRF protection Modern browsers default to Lax

The complete security baseline for an authentication cookie is: Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax; Path=/


How to Run a Secure Cookie Test

Check any website's Set-Cookie headers for Secure, HttpOnly, and SameSite flags in seconds.

1

Enter the Domain Name

Type the domain to test — for example, example.com — without the https:// prefix. The tool adds it automatically.
2

Run the Test

Click Check Cookie Security. The server sends a live GET request to the domain and parses all Set-Cookie response headers.
3

Read the Cookie Table

Each row shows one cookie name with a ✓ or ✗ for Secure, HttpOnly, and the detected SameSite value.
4

Act on Missing Flags

For any flag marked absent, see the Technical Details section below for the server-side configuration fix.

How Secure Cookie Test Works

HTTP cookies are governed by RFC 6265 (HTTP State Management Mechanism, IETF, April 2011), which defines the Set-Cookie response header and the Secure and HttpOnly attributes. The SameSite attribute was introduced through browser consensus and formalized in RFC 6265bis (widely implemented since Chrome 80, Firefox 79, Safari 13).

The tool sends a GET request — not HEAD — to the domain root. HEAD responses frequently omit Set-Cookie headers because cookies are typically issued during session initiation, not on header-only responses. GET requests follow the same code path as a browser's initial page load, returning the full response header set.

The cookie name prefixes __Secure- and __Host- (defined in RFC 6265bis) provide additional browser-enforced hardening. A __Host- cookie must carry Secure, must omit the Domain attribute, and must set Path=/ — preventing subdomain-based session fixation attacks.

Results reflect the server's live configuration at query time. Cookies set only on authenticated routes or subpaths are not returned by the root URL test.

Do it yourself

How to Check Cookie Security Flags Without an Online Tool

The Set-Cookie header is visible in any HTTP response. Use these commands to inspect cookie attributes directly from the terminal.

Mac / Linux curl

curl -sL -D - https://example.com -o /dev/null | grep -i set-cookie

The -L flag follows redirects to the final destination. Each Set-Cookie line shows the full attribute string.

Windows PowerShell

$r = Invoke-WebRequest -Uri "https://example.com" -MaximumRedirection 5
$r.Headers["Set-Cookie"]

Mac / Linux curl (verbose, full headers)

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

The online tool queries from a neutral external server — results reflect the server's response to an external request, which may differ from a logged-in session or a request originating from your local network.

Common Uses for Secure Cookie Test

Post-HTTPS migration verification. A developer migrates an application from HTTP to HTTPS and needs to confirm that session cookies have been updated. After the migration, they run the test and confirm the session cookie now carries the Secure flag and SameSite=Lax. A legacy analytics cookie still lacks HttpOnly — flagged for a server-side configuration update before the next release.

Pre-launch security audit. A security engineer auditing a client's web application runs the test against the staging domain. Results show authentication cookies missing both HttpOnly and Secure — a critical finding that would expose session tokens to network interception and XSS theft. The engineer documents each Set-Cookie line and the missing attributes for the development team.

OAuth integration SameSite validation. A backend developer switches a cookie's SameSite policy from Strict to None to support a new cross-site OAuth flow. The test confirms the SameSite=None cookie now correctly carries the Secure flag — required by RFC 6265bis, and rejected by Chrome, Firefox, and Safari without it.


Frequently Asked Questions

What does the Secure cookie flag do?
The Secure flag restricts the cookie to HTTPS-only transmission per RFC 6265, Section 4.1.2.5. Without it, the browser sends the cookie over unencrypted HTTP as well, exposing it to any observer on the network path. Every authentication and session cookie must carry the Secure flag — it is non-negotiable on any site using HTTPS.
What does the HttpOnly attribute do?
HttpOnly prevents client-side scripts from accessing the cookie via document.cookie or the Cookie Store API per RFC 6265, Section 4.1.2.6. Without it, an XSS exploit can steal session tokens directly with a one-line script. Session tokens, authentication cookies, and CSRF tokens must always be HttpOnly.
What is the SameSite attribute and which value should I use?
SameSite controls whether the browser sends the cookie on cross-site requests. Strict blocks it on all cross-site requests. Lax allows it on top-level navigations (link clicks) but blocks subresource requests — the recommended default for most applications. None allows all cross-site requests but requires the Secure flag; browsers reject SameSite=None without Secure per RFC 6265bis. If SameSite is absent, modern browsers default to Lax.
Why does the test find no cookies for my domain?
Cookies are issued by the server in response to specific requests — typically login flows or session-initializing routes, not the site root. The test checks the root URL of the domain. If your application sets cookies only after authentication, test the exact URL that triggers the Set-Cookie header rather than the homepage. A homepage returning no Set-Cookie headers is expected behavior for most sites.
How accurate is the Secure Cookie Test?
The test sends a live GET request to the domain root and parses every Set-Cookie header in the HTTP response. Results reflect the server's live configuration at query time — not cached, not browser-specific. Cookies set only on authenticated pages or specific paths are not visible from the root URL. The tool reads only the headers returned by the tested URL.
Do you store the domains I check?
No. The domain is used to send a single HTTPS GET request and parse the response headers. Neither the domain, the cookies, nor any result data is stored or logged. All processing is server-side and stateless.

Related Guides

Guide What Is a VPN? How Virtual Private Networks Protect Your Traffic
Cookie security protects server-issued session state; a VPN encrypts the transport layer that carries those cookies across the network. Understanding both layers is essential for a complete web security posture.
Guide What Is a Proxy Server?
Proxy servers sit between a browser and the origin server. Cookies transiting through a proxy without the Secure flag can be read in cleartext. This guide explains how proxies interact with HTTP traffic, including cookie headers.