Cookie Security Analyzer

What Are Cookie Security Flags?

Every HTTP cookie can carry attributes that control how the browser handles it. Three of these attributes exist purely for security: Secure, HttpOnly, and SameSite. They cost nothing to implement, add zero latency, and block entire categories of attacks. Yet a 2024 study by the University of Leuven found that 43% of Alexa Top 10,000 sites still serve at least one session cookie without all three flags set.

Secure restricts the cookie to HTTPS connections only. Without it, the cookie travels in cleartext over any HTTP request. Which means anyone performing a man-in-the-middle attack on a coffee shop Wi-Fi network can capture it with tcpdump in under 10 seconds.

HttpOnly tells the browser to hide the cookie from JavaScript per the MDN cookie security specification. The document.cookie API will not return it. This is your primary defense against cross-site scripting (XSS) attacks that attempt to steal session tokens.

SameSite controls whether the browser sends the cookie on cross-origin requests. Set to Strict or Lax, it prevents CSRF attacks by ensuring the cookie only accompanies requests that originate from your own domain. Chrome, Edge, and Firefox default to Lax when no SameSite attribute is specified (see web.dev SameSite guide), but Safari still defaults to None in some configurations.

Cookie Flags Reference

SameSite Explained: Strict vs Lax vs None

The SameSite attribute is the most misunderstood cookie flag. Here is exactly when each value applies.

Cookie-Based Attacks You Should Know

How to Set Secure Cookies (Code Examples)

Copy-paste these snippets into your backend. Each sets a session cookie with all three security flags.

res.cookie('session', token, {
  httpOnly: true,    // block document.cookie access
  secure: true,      // HTTPS only
  sameSite: 'lax',   // block cross-site POST
  maxAge: 3600000,   // 1 hour in milliseconds
  path: '/',
});

import { cookies } from 'next/headers';

const cookieStore = await cookies();
cookieStore.set('session', token, {
  httpOnly: true,
  secure: process.env.NODE_ENV === 'production',
  sameSite: 'lax',
  maxAge: 60 * 60, // 1 hour in seconds
  path: '/',
});

# settings.py
SESSION_COOKIE_SECURE = True
SESSION_COOKIE_HTTPONLY = True
SESSION_COOKIE_SAMESITE = 'Lax'
CSRF_COOKIE_SECURE = True
CSRF_COOKIE_HTTPONLY = True

# Or set manually in a view:
response.set_cookie(
    'session', token,
    httponly=True, secure=True,
    samesite='Lax', max_age=3600,
)

// config/session.php
'secure' => env('SESSION_SECURE_COOKIE', true),
'http_only' => true,
'same_site' => 'lax',

// Or manually:
return response()->cookie(
    'session', $token, 60, // 60 minutes
    '/', null, true, true  // secure=true, httpOnly=true
)->withCookie(
    cookie('session', $token)->withSameSite('Lax')
);

# config/initializers/session_store.rb
Rails.application.config.session_store :cookie_store,
  key: '__Host-session',
  secure: Rails.env.production?,
  httponly: true,
  same_site: :lax

# Or in a controller:
cookies[:session] = {
  value: token,
  httponly: true,
  secure: true,
  same_site: :lax,
  expires: 1.hour.from_now,
}

Cookies and GDPR / Privacy Compliance

Cookie security and cookie privacy are different problems, but they overlap. Under the EU'sGeneral Data Protection Regulation (GDPR) and the ePrivacy Directive, you must obtain informed consent before setting non-essential cookies. Here is what that means in practice.

Learn more about GDPR compliance for developers.

Common Cookie Security Mistakes

Frequently Asked Questions

Related Security Tools