To tell whether a website's cookies are secure, open your browser's DevTools (F12 → Application → Cookies in Chrome, or Storage → Cookies in Firefox) and check three columns on every session or login cookie: Secure must be checked, HttpOnly must be checked, and SameSite must read Strict or Lax. Secure forces the cookie to travel only over HTTPS so it cannot be sniffed on the network; HttpOnly hides it from JavaScript so an XSS bug cannot steal it; SameSite stops the browser from sending it on cross-site requests so it cannot be abused for CSRF. A session cookie missing any of the three, or holding recognizable data (a username, an email, a token you can decode) in its value, is insecure regardless of how modern the site looks.
That's the checklist an AI Overview will hand you. What it can't show you is the why behind each flag, the exact Set-Cookie strings that pass and fail, the decision tree for which SameSite value a given cookie should use, or how to read the browser prefixes (__Secure-, __Host-) that quietly enforce all of this at the browser level. The diagram and tables below map the whole cookie surface so you can audit a site in under a minute — and fix your own.
For security professionals auditing websites, developers reviewing implementations, or privacy-conscious users evaluating sites they interact with, understanding how to assess cookie security is essential. This guide provides a systematic approach to evaluating cookie configurations, identifying security issues, and understanding what separates secure cookies from dangerous ones.
Key Indicators of Secure Cookies
Several attributes and configurations signal that cookies are properly secured against common attacks.
1. The Secure Flag is Present
What to Look For: Secure attribute set on all cookies for HTTPS websites, ensuring cookies only transmit over encrypted connections.
Why It Matters: Without Secure, cookies sent over HTTP can be intercepted by attackers on the same network, enabling session hijacking through man-in-the-middle attacks. On public WiFi, unencrypted cookie transmission exposes users to trivial credential theft.
How to Check:
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax
The Secure attribute should appear on every cookie for sites using HTTPS (which, in 2025, should be all sites handling any sensitive data).
Red Flag: Any cookie on an HTTPS website lacking the Secure flag. This indicates the cookie could be sent over HTTP if the connection is downgraded, either intentionally by attackers or accidentally through mixed content.
2. HttpOnly Flag on Session and Authentication Cookies
What to Look For: HttpOnly attribute on cookies used for authentication, session management, or storing sensitive identifiers.
Why It Matters: HttpOnly prevents JavaScript from accessing cookies via document.cookie, defending against Cross-Site Scripting (XSS) attacks that attempt cookie theft. Without HttpOnly, any XSS vulnerability instantly compromises user sessions.
How to Check:
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax
Session cookies, authentication tokens, remember-me tokens, and any cookie containing sensitive identifiers should be HttpOnly.
Red Flag: Session or authentication cookies accessible to JavaScript. This is a critical vulnerability—if the site has any XSS flaw (and most sites have at least minor XSS issues), session cookies can be stolen.
Acceptable Exception: Non-sensitive cookies like theme preferences, language selection, or UI state don't need HttpOnly because client-side JavaScript legitimately needs access to implement functionality.
3. SameSite Attribute is Configured
What to Look For: SameSite attribute set to Strict, Lax, or explicitly None (with Secure) based on cookie purpose.
Why It Matters: SameSite controls when cookies are sent with cross-site requests, defending against Cross-Site Request Forgery (CSRF) attacks. Modern browsers default to SameSite=Lax, but explicit configuration is better practice.
Recommended Settings:
- Session cookies: SameSite=Lax or SameSite=Strict
- CSRF tokens: SameSite=Strict
- Third-party integrations: SameSite=None; Secure (only when necessary)
How to Check:
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax
Red Flag:
- Session cookies with SameSite=None (allows cross-site transmission unnecessarily)
- Any cookie with SameSite=None but missing Secure flag (browsers will reject)
- Pre-2020 sites with no SameSite attribute on any cookie (vulnerable in older browsers)
Which SameSite value should a given cookie use? The choice is almost mechanical once you know what the cookie is for:
Quick-Reference: What Each Attribute Does and When to Use It
| Attribute | What it does | Use on | Skip / avoid when |
|---|---|---|---|
| Secure | Cookie sent only over HTTPS | Every cookie on an HTTPS site | Never skip on a real site |
| HttpOnly | Blocks JavaScript (document.cookie) access | Session, auth, remember-me, CSRF-session cookies | Preference/UI cookies JS must read; double-submit CSRF token cookie |
| SameSite=Strict | Never sent cross-site | CSRF tokens, banking/high-value sessions | Login-via-external-link UX matters (use Lax) |
| SameSite=Lax | Sent on top-level cross-site GETs only | General session cookies (browser default) | You need true cross-site sending (use None) |
| SameSite=None | Sent on all cross-site requests | SSO, embeds, 3rd-party integrations — with Secure | First-party session/auth cookies (red flag) |
__Host- prefix | Browser enforces Secure + Path=/ + no Domain | The most sensitive session cookie | You need a Domain attribute or subdomain scope |
__Secure- prefix | Browser enforces Secure flag | Sensitive cookies needing a Domain scope | Non-sensitive cookies |
| Short Max-Age | Limits stolen-cookie usefulness | Session/auth cookies (30 min–2 hr) | Non-sensitive preference cookies (long is fine) |
4. Appropriate Expiration Times
What to Look For: Short-lived expiration for sensitive cookies (minutes to hours), longer expiration only for non-sensitive preference cookies.
Why It Matters: Cookies that remain valid indefinitely extend the window of opportunity for stolen credentials. Session cookies should expire after reasonable inactivity periods, forcing re-authentication.
Best Practices:
- Session cookies: 30 minutes to 2 hours (Max-Age=1800 to Max-Age=7200)
- Remember-me tokens: Days to weeks (Max-Age=604800 for 1 week)
- Preference cookies: Months to years (as they're non-sensitive)
How to Check:
Set-Cookie: session_id=abc123; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
Red Flag:
- Session cookies with no expiration (remain valid forever)
- Authentication cookies valid for months or years
- Extremely long expiration on sensitive data
5. No Sensitive Data in Cookie Values
What to Look For: Cookie values contain only session identifiers or encrypted tokens, not actual sensitive data in plain text.
Why It Matters: Cookies are stored on user devices and transmitted with every request. Storing passwords, credit card numbers, social security numbers, or other sensitive data directly in cookies is a critical security flaw.
Secure Pattern:
Set-Cookie: session_id=a1b2c3d4e5f6; Secure; HttpOnly
// Server-side session stores actual user data
Insecure Pattern:
Set-Cookie: user_data=username:john|password:abc123|ssn:123-45-6789
// Sensitive data in plain text - NEVER DO THIS
How to Check: Inspect cookie values (using browser DevTools) and look for recognizable sensitive information like:
- Passwords or password hashes
- Credit card numbers
- Social security numbers
- API keys or secrets
- Full names and addresses in plain text
Red Flag: Any recognizable sensitive information in cookie values, especially in plain text. Even if "encrypted," sensitive data should be stored server-side and referenced only by session ID.
6. Proper Cookie Prefixes
What to Look For: Use of __Secure- or __Host- cookie prefixes for sensitive cookies, enforcing additional security requirements.
Why It Matters: Cookie prefixes provide an extra layer of protection by enforcing security attributes at the browser level, preventing misconfiguration.
__Secure- Prefix:
Set-Cookie: __Secure-session_id=abc123; Secure; HttpOnly; SameSite=Lax
Enforces that cookie must have Secure attribute. Browsers reject __Secure- cookies without Secure flag.
__Host- Prefix:
Set-Cookie: __Host-session_id=abc123; Secure; HttpOnly; SameSite=Lax; Path=/
Enforces:
- Must have Secure attribute
- Must not have Domain attribute (sent only to exact host)
- Must have Path=/
Use Cases:
- Critical session cookies: __Host- prefix
- Security-sensitive cookies: __Secure- prefix
- Regular cookies: No prefix needed
Red Flag: High-security applications (banking, healthcare, government) not using cookie prefixes on authentication cookies.
Tools and Methods for Cookie Analysis
Several approaches enable systematic cookie security assessment.
Method 1: Browser Developer Tools
All modern browsers include built-in cookie inspection tools.
Chrome/Edge DevTools:
- Open DevTools (F12 or Ctrl+Shift+I / Cmd+Option+I)
- Navigate to Application tab
- Expand "Cookies" in left sidebar
- Select domain to inspect
- Review table showing all cookie attributes
What to Look For:
- Name column: Cookie identifiers
- Value column: Cookie contents (check for sensitive data)
- Domain column: Which domains can access cookie
- Path column: Which paths cookie applies to
- Expires/Max-Age column: When cookie expires
- HttpOnly column: Checkmark indicates HttpOnly is set
- Secure column: Checkmark indicates Secure is set
- SameSite column: Shows Strict, Lax, or None
- Partition Key column: Indicates cookie partitioning status
Firefox Developer Tools:
- Open DevTools (F12)
- Go to Storage tab
- Expand Cookies
- Select domain
- Review cookie properties
Similar layout showing all cookie attributes for inspection.
Method 2: Cookie Analyzer Tools
Specialized tools provide automated cookie security analysis.
Online Cookie Analyzers:
- Scan all cookies on a page
- Flag security issues automatically
- Provide recommendations
- Compare against security best practices
Features to Look For:
- Automatic detection of missing Secure flags
- Identification of authentication cookies without HttpOnly
- SameSite misconfiguration alerts
- Sensitive data detection in cookie values
- Cookie prefix recommendations
- Expiration analysis
Method 3: Security Scanners
Web application security scanners include cookie analysis as part of comprehensive assessments.
OWASP ZAP (Zed Attack Proxy):
- Free, open-source security scanner
- Automated cookie security checks
- Reports missing security attributes
- Identifies insecure cookie patterns
Burp Suite:
- Professional security testing tool
- Comprehensive cookie analysis
- Custom cookie rules and checks
- Integration with manual testing workflows
Acunetix, Netsparker, Qualys:
- Commercial scanners with cookie security modules
- Automated vulnerability detection
- Compliance checking (PCI-DSS, GDPR)
- Detailed remediation guidance
Method 4: Browser Extensions
Privacy and security-focused browser extensions continuously monitor cookies.
Cookie AutoDelete:
- Automatically deletes cookies when tabs close
- Whitelist/blacklist functionality
- Shows which cookies are set by each site
EditThisCookie:
- Cookie manager and editor
- Inspect and modify cookies
- Export/import cookie data
- Security attribute display
Privacy Badger / uBlock Origin:
- Block tracking cookies
- Identify third-party cookies
- Show which domains set cookies on each page
Red Flags: Signs of Insecure Cookies
Certain patterns indicate poor cookie security that should raise immediate concerns.
Critical Red Flags
1. Session Cookies Without HttpOnly: Indicates site is vulnerable to session hijacking via XSS. Any XSS flaw (even minor ones) can compromise all user sessions.
Severity: Critical Attack Vector: XSS-based session theft Recommendation: Add HttpOnly to all session cookies immediately
2. Any Cookies Without Secure on HTTPS Sites: Indicates cookies may transmit over HTTP, enabling interception on unsecured networks.
Severity: High Attack Vector: Man-in-the-middle attacks, especially on public WiFi Recommendation: Add Secure to all cookies on HTTPS sites
3. Sensitive Data Stored in Cookie Values: Passwords, credit cards, SSNs, or other sensitive data visible in cookies is critical vulnerability.
Severity: Critical Attack Vector: Direct data exposure, regulatory violation Recommendation: Never store sensitive data in cookies; use session IDs referencing server-side data
4. Authentication Cookies with Very Long Expiration: Session cookies valid for months or years extend the window for stolen cookie exploitation.
Severity: Medium to High Attack Vector: Extended session hijacking window Recommendation: Implement reasonable session timeouts (30-120 minutes)
5. SameSite=None on Session Cookies: Unnecessarily allows cross-site transmission of authentication cookies, enabling CSRF attacks.
Severity: High Attack Vector: CSRF attacks Recommendation: Change to SameSite=Lax or SameSite=Strict
Warning Signs
1. Many Third-Party Cookies: Large numbers of tracking cookies from advertising and analytics platforms indicate potential privacy issues, though not necessarily security vulnerabilities.
2. No Cookie Prefixes: While not strictly required, absence of __Secure- or __Host- prefixes on high-security applications suggests less rigorous security practices.
3. Inconsistent Cookie Security: Some cookies secured properly while others aren't indicates inconsistent security practices and potential oversight.
4. Legacy Cookie Names: Old cookie naming conventions (PHPSESSID, JSESSIONID, ASP.NET_SessionId) may indicate older code that hasn't been reviewed for modern security standards.
Security Best Practices: The Ideal Configuration
A well-secured website follows these cookie security patterns:
For Session/Authentication Cookies
Ideal Configuration:
Set-Cookie: __Host-session=abc123xyz;
Secure;
HttpOnly;
SameSite=Strict;
Path=/;
Max-Age=3600
Characteristics:
- __Host- prefix enforcing strict security
- Secure flag (HTTPS-only transmission)
- HttpOnly flag (JavaScript can't access)
- SameSite=Strict (maximum CSRF protection)
- Path=/ (applies to entire site)
- Max-Age=3600 (1-hour expiration)
For CSRF Tokens
Ideal Configuration:
Set-Cookie: __Secure-csrf_token=xyz789;
Secure;
SameSite=Strict;
Path=/;
Max-Age=3600
Characteristics:
- __Secure- prefix
- Secure flag
- NOT HttpOnly (JavaScript needs to read for AJAX requests)
- SameSite=Strict
- Short expiration matching session lifetime
For User Preferences
Ideal Configuration:
Set-Cookie: preferences=theme:dark|lang:en;
Secure;
SameSite=Lax;
Path=/;
Max-Age=31536000
Characteristics:
- Secure flag
- NOT HttpOnly (client-side JavaScript needs access)
- SameSite=Lax (no cross-site restrictions needed)
- Long expiration (1 year) acceptable for preferences
For Third-Party Integrations
Ideal Configuration:
Set-Cookie: integration_token=token123;
Secure;
SameSite=None;
Path=/;
Max-Age=7200
Characteristics:
- Secure flag (required with SameSite=None)
- SameSite=None (allows cross-site access when necessary)
- Reasonable expiration (2 hours)
- Only used when cross-site access is truly necessary
Testing Your Own Website
For developers and site owners, systematic testing ensures cookie security.
Testing Checklist
1. Enumerate All Cookies: List every cookie your site sets across all pages and user actions (login, checkout, preferences, etc.).
2. Review Each Cookie: For each cookie, verify:
- Secure flag present (if site uses HTTPS)
- HttpOnly set (if cookie contains sensitive data)
- Appropriate SameSite value (Strict/Lax for same-site, None only if necessary)
- Reasonable expiration time
- No sensitive data in cookie value
- Appropriate Domain and Path settings
3. Test Different Scenarios:
- Anonymous user browsing
- Logged-in user interaction
- Session timeout behavior
- Cross-origin requests (if applicable)
- Third-party integrations
4. Use Automated Tools: Run security scanners (OWASP ZAP, Burp Suite) to catch issues you might miss manually.
5. Review Framework Defaults: Check that your web framework's default cookie settings are secure. Many frameworks require explicit configuration for optimal security.
Common Framework Configurations
Express.js (Node.js):
app.use(session({
secret: process.env.SESSION_SECRET,
name: '__Host-session',
cookie: {
secure: true, // Requires HTTPS
httpOnly: true, // Prevents JS access
sameSite: 'strict', // CSRF protection
maxAge: 3600000 // 1 hour
}
}));
Django (Python):
# settings.py
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = 'Strict'
SESSION_COOKIE_AGE = 3600
SESSION_COOKIE_NAME = '__Host-sessionid'
CSRF_COOKIE_SECURE = True
CSRF_COOKIE_SAMESITE = 'Strict'
ASP.NET Core (C#):
services.AddSession(options =>
{
options.Cookie.Name = "__Host-session";
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
options.Cookie.HttpOnly = true;
options.Cookie.SameSite = SameSiteMode.Strict;
options.IdleTimeout = TimeSpan.FromMinutes(60);
});
Conclusion
Determining whether a website's cookies are secure requires examining multiple security attributes and configuration patterns. Secure cookies consistently implement the Secure flag on HTTPS sites, use HttpOnly for authentication cookies, configure appropriate SameSite restrictions, maintain reasonable expiration times, and avoid storing sensitive data directly in cookie values.
Red flags like session cookies without HttpOnly, missing Secure flags, or SameSite=None on authentication cookies indicate significant vulnerabilities that attackers actively exploit. Modern security-conscious websites implement all three critical attributes—Secure, HttpOnly, and SameSite—on sensitive cookies, often with additional hardening through cookie prefixes.
For users evaluating websites, browser developer tools provide immediate visibility into cookie security. For developers and security professionals, systematic testing with automated scanners combined with manual inspection ensures comprehensive cookie security assessment. In 2025, there's no excuse for insecure cookie configurations—the tools, knowledge, and framework support exist to implement proper cookie security on every website.
Want to analyze cookie security for websites you visit or manage? Use our Cookie Analyzer tool to automatically inspect all cookies on a page, identify security issues, and receive specific recommendations for improving cookie configuration.