Cookie Security for Ecommerce: Secure, HttpOnly, SameSite Explained

Three cookie attributes — Secure, HttpOnly, and SameSite — determine whether your session tokens are safe from the three most common attacks against authenticated ecommerce sessions. Most stores have one of them right, two if they're lucky, all three only when someone has done the explicit work to verify it.

The default cookie configuration on most ecommerce platforms is "good enough" for casual users but leaves session tokens vulnerable to specific attack patterns that have been documented for over a decade. Here's what each attribute does, why it matters for ecommerce specifically, and how to audit your store's current state.

The Three Attributes

Secure

The Secure attribute tells the browser: only send this cookie over HTTPS connections. Without it, a session cookie can leak in plaintext over HTTP — including the initial HTTP request that gets redirected to HTTPS, which still includes the cookie if Secure isn't set.

Attack vector: network sniffing on public Wi-Fi, malicious ISP injection, MITM on a compromised router. The attacker captures the cookie, replays it, and is now logged in as your customer.

Required for: any cookie containing authentication data, session IDs, or anything an attacker shouldn't see in plaintext.

HttpOnly

The HttpOnly attribute tells the browser: don't expose this cookie to JavaScript. document.cookie won't see it. fetch() with credentials will still send it, but client-side scripts can't read it.

Attack vector: cross-site scripting (XSS). An attacker injects a script that reads document.cookie and exfiltrates session tokens to an attacker-controlled server. With HttpOnly set, the XSS still executes but the session cookie is invisible to the script.

Required for: session and authentication cookies. Read-only flags or UI preferences (cart-open state, theme) can stay accessible to JavaScript — those don't need HttpOnly.

SameSite

The SameSite attribute controls when the cookie is sent in cross-site requests. Three values:

• Strict: never sent on cross-site requests. The user clicks a link from Facebook to your store, the cookie isn't sent — they appear logged out until they navigate within your site.
• Lax: sent on top-level navigation (link clicks) but not on cross-site embedded requests (image loads, iframes, fetch). This is the default in modern browsers and balances security with usability.
• None: sent on all requests. Required for legitimate cross-site usage (third-party embeds, federated auth) but must be paired with Secure.

Attack vector: cross-site request forgery (CSRF). An attacker tricks a logged-in customer into visiting a malicious page that submits a request to your store (e.g., changing shipping address, placing an order). Without SameSite, the customer's cookie is sent automatically and the request succeeds.

Required for: all authentication and session cookies. Use Lax as the baseline; use Strict for high-sensitivity tokens (admin sessions, payment authorization); use None only when you need cross-site functionality and pair it with Secure.

The Right Configuration for Ecommerce

For a typical ecommerce session cookie:

Set-Cookie: session_id=abc123;
  Secure;
  HttpOnly;
  SameSite=Lax;
  Path=/;
  Max-Age=2592000

For an admin session (Shopify admin, WooCommerce wp-admin, BigCommerce control panel):

Set-Cookie: admin_session=def456;
  Secure;
  HttpOnly;
  SameSite=Strict;
  Path=/admin;
  Max-Age=14400

For a third-party-embedded analytics or marketing cookie (legitimately cross-site):

Set-Cookie: analytics_id=ghi789;
  Secure;
  SameSite=None;
  Path=/;
  Max-Age=31536000

Common Misconfigurations

1. SameSite=None without Secure

Modern browsers reject this combination — the cookie is dropped silently. If you intended to support cross-site usage and forgot the Secure flag, the cookie just doesn't work and you'll see mysterious "session lost" reports from a subset of users.

2. Session cookies without HttpOnly

Default behavior on many older platforms. If your site has any user-generated content, third-party widgets, or marketplace integrations, an XSS vulnerability somewhere becomes an account takeover.

3. Mixed Secure flags within one site

Some cookies have Secure, some don't. The non-Secure ones leak on the first HTTP request before the HTTPS redirect. If any of them carry session-relevant data, the redirect-to-HTTPS doesn't save you.

4. SameSite default behavior

Pre-2020 browsers defaulted to SameSite=None. Modern browsers default to Lax, but if your platform sets cookies before the browser applies the default, behavior depends on browser version and creates a confusing inconsistency. Always set SameSite explicitly.

5. Long-lived cookies without Max-Age limits

A "remember me" cookie that lives forever is a perpetual attack surface. Use rolling sessions (re-issue on activity) and set sensible Max-Age caps — 30 days for "remember me", 1 hour for admin sessions, 15 minutes for payment authorization.

Auditing Your Current Cookies

Three ways to check:

1. Browser DevTools. Application → Cookies → click your domain. Inspect each cookie's HttpOnly, Secure, SameSite columns. Tedious but free.
2. curl -I -c. curl -I -c cookies.txt https://your-store.com/ followed by inspecting cookies.txt for the attributes. Misses cookies set by JavaScript after page load.
3. Continuous monitoring. The Cookie Security Checker audits all cookies set on a URL with HttpOnly/Secure/SameSite analysis and a per-cookie risk rating.

The Platform Defaults

• Shopify: session cookies set with HttpOnly + Secure + SameSite=Lax by default. Custom apps often don't follow the same convention — audit any cookies set by your installed apps.
• WooCommerce: WordPress core sets HttpOnly on auth cookies but NOT Secure unless you've configured FORCE_SSL_ADMIN in wp-config.php. Plugins set their own cookies with varying defaults.
• BigCommerce: hosted session cookies follow modern standards. Headless setups with custom auth need explicit configuration.
• Magento / Adobe Commerce: configurable in admin → stores → configuration → web → default cookie settings. Check that "Use HTTP Only" and "Cookie Lifetime" are set; SameSite requires custom code or a recent extension.
• Custom/Headless: entirely up to you. Set explicit attributes on every Set-Cookie.

The Compliance Angle

PCI-DSS doesn't mandate specific cookie attributes but requires "strong access control" — auditors increasingly cite missing HttpOnly/Secure as findings. SOC 2 Type II reports often include cookie security as a control. Some bug bounty programs pay for missing-attribute reports as low/medium severity. Worth fixing proactively.

Bottom Line

Cookie attributes are infrastructure, not features. Set Secure + HttpOnly + SameSite=Lax as the default for every authentication-adjacent cookie, escalate to SameSite=Strict for admin and payment, and only use SameSite=None when you have a documented cross-site need. Audit at least quarterly — third-party scripts, plugin updates, and platform migrations regularly add new cookies that don't follow your standards.