Insecure cookie
Moderate effortSet the HttpOnly, Secure, and SameSite=Strict flags on every session and CSRF cookie your store sets so they cannot be stolen by malicious scripts or sent over unencrypted connections.
What it is
Every time a visitor lands on your store, their browser receives small data files called cookies — one of which typically holds their login session or a CSRF token (a secret code that proves form submissions came from your real site, not an attacker). Each cookie can carry protective "flags" that tell the browser how to handle it safely. The three critical flags are: **HttpOnly** (JavaScript running on the page cannot read the cookie, so a hacked ad script cannot steal it), **Secure** (the browser only sends the cookie over HTTPS, never plain HTTP), and **SameSite=Strict** (the browser refuses to send the cookie when a request originates from a third-party site, blocking cross-site request forgery attacks). When any of these flags are missing, the cookie is left partially unprotected.
Why it matters
A missing HttpOnly flag is the primary enabler of session-hijacking via Cross-Site Scripting (XSS): if even one ad, chat widget, or third-party script on your page is ever compromised, it can silently read your customers' session cookies and hand them to an attacker, who then logs in as that customer and sees their orders, saved addresses, and payment methods. A missing Secure flag risks cookies being transmitted in plain text if a customer ever hits an HTTP link, exposing their session to network eavesdroppers (especially on public Wi-Fi). A missing SameSite flag enables Cross-Site Request Forgery (CSRF), where a malicious page tricks a logged-in customer's browser into submitting unwanted actions — like changing their email or placing a fraudulent order — on your store. Beyond customer harm, a breach involving stolen session tokens can trigger PCI-DSS violations, GDPR fines, and lasting reputational damage that directly kills revenue.
How to fix it
- Audit all cookies your store sets — use browser DevTools (Application → Cookies) to list every cookie and note which flags are missing.
- For cookies your platform or framework sets (session, CSRF), locate the cookie configuration in your platform's admin, theme settings, or server-side config file and enable HttpOnly, Secure, and SameSite=Strict (or Lax if Strict breaks legitimate cross-site flows like OAuth).
- For cookies set by third-party apps, plugins, or scripts, update each integration to its latest version (vendors often patch this) and check whether the integration has its own cookie-settings panel.
- For any custom-coded middleware or checkout extensions, update the Set-Cookie HTTP response header to include all three flags: `Set-Cookie: name=value; Path=/; Secure; HttpOnly; SameSite=Strict`.
- Verify the fix by reloading the store in a browser, opening DevTools → Application → Cookies, and confirming each relevant cookie shows a checkmark (✓) in the HttpOnly and Secure columns and shows SameSite = Strict or Lax.
- Re-test after every major platform upgrade or new app/plugin install, because updates can reset cookie configuration.
Set-Cookie: CSRFTOKEN=abc123; Path=/; Secure; HttpOnly; SameSite=StrictFix it on your platform
Pick your platform for the exact steps.
How to fix insecure cookie on Shopify
- Shopify's own session and cart cookies (e.g., _session_id, _secure_session_id) are managed by Shopify's infrastructure and already carry Secure and HttpOnly on Plus plans and standard storefronts — verify in DevTools.
- For CSRF tokens in custom theme forms, Shopify injects them via `{{ form.errors }}` and Liquid — you do not set these manually; ensure your theme uses standard Shopify form tags rather than custom JavaScript-built forms.
- For cookies set by custom apps or scripts injected via theme.liquid or Script Tags: go to Online Store → Themes → Edit Code → theme.liquid and review any `document.cookie` assignments in custom JavaScript; add '; Secure; SameSite=Strict' to every assignment.
- For private/custom app backends (Node.js, Ruby, etc.) deployed on external servers that set cookies: update your server's session middleware (e.g., express-session `cookie: { httpOnly: true, secure: true, sameSite: 'strict' }`) and redeploy.
- Install a trusted security scanner app (e.g., Shopify Security Scan in the App Store) to continuously monitor cookie flags after each change.
How to fix insecure cookie on WooCommerce
- Go to WordPress Admin → Plugins → Add New and install the 'Really Simple SSL' plugin (free) or 'Sucuri Security'; these plugins enforce Secure and SameSite cookie flags site-wide via PHP filters.
- Alternatively, open your theme's functions.php (Appearance → Theme File Editor → functions.php) or a site-specific plugin and add: `add_filter('session_cookie_params', function($params){ $params['secure'] = true; $params['httponly'] = true; $params['samesite'] = 'Strict'; return $params; });`
- For WooCommerce's own session cookie (wp_woocommerce_session_*), it is set by WooCommerce core. Update WooCommerce to the latest version (Dashboard → Updates) to get current security flags.
- For WordPress auth cookies (wordpress_logged_in_*, wordpress_sec_*): add `@ini_set('session.cookie_httponly', 1);` and `@ini_set('session.cookie_secure', 1);` to wp-config.php.
- Verify via browser DevTools → Application → Cookies that all wp_ and woocommerce_ cookies show HttpOnly ✓, Secure ✓, and SameSite = Strict/Lax.
How to fix insecure cookie on BigCommerce
- BigCommerce's core platform cookies (e.g., SHOP_SESSION_TOKEN, XSRF-TOKEN) are set server-side by BigCommerce. Ensure your store is on HTTPS (Settings → Setup → SSL Certificate) — this is a prerequisite for Secure flag delivery.
- For the CSRF token cookie specifically: BigCommerce handles this automatically in Stencil themes via `{{inject 'secureBaseUrl' settings.secure_base_url}}` — do not attempt to replicate this manually.
- For custom cookies set in Stencil theme JavaScript (assets/js/): open the relevant JS file in Page Builder → Theme Files or via Stencil CLI, find any `document.cookie = ` assignments, and append `; Secure; SameSite=Strict; HttpOnly` (note: HttpOnly cannot be set via JS — move cookie creation to a server-side API route or custom app backend).
- For custom app backends connecting to BigCommerce via API: in your server middleware, set cookie options to httpOnly: true, secure: true, sameSite: 'strict' before setting any response cookies.
- Submit a support ticket to BigCommerce (Help → Contact Us) if a platform-managed cookie is found missing flags, as these are within their infrastructure control.
How to fix insecure cookie on Adobe Commerce (Magento)
- Log in to the Admin Panel and navigate to Stores → Configuration → General → Web → Session Cookie Management.
- Set 'Cookie Lifetime' appropriately, then locate and enable 'Cookie Restriction Mode'; ensure 'Use Secure Cookie' is set to 'Yes' and 'HTTP Only' is set to 'Yes'.
- For SameSite: in Magento 2.3.5+, go to Stores → Configuration → General → Web → Default Cookie Settings and set 'Cookie SameSite' to 'Strict'.
- If those UI options are unavailable (older versions), add to app/etc/env.php under 'session' config: `'cookie_secure' => 1, 'cookie_httponly' => 1, 'cookie_samesite' => 'Strict'`.
- Deploy config changes: run `bin/magento config:set web/cookie/cookie_httponly 1`, `bin/magento config:set web/cookie/cookie_secure 1`, then `bin/magento cache:flush` via SSH.
- Verify in browser DevTools → Application → Cookies that PHPSESSID and form_key cookies all carry the correct flags.
How to fix insecure cookie on Wix
- Wix-managed session cookies are set by Wix's infrastructure; you cannot directly modify their flags. Ensure your site is published with HTTPS enabled (Settings → General → SSL Certificate → toggle On).
- For cookies set in Wix Velo (custom JavaScript backend): in your site's backend code (e.g., http-functions.js or a Velo web module), use the `wix-http-functions` response API — set cookie options explicitly: `response.cookies.set('name', 'value', { httpOnly: true, secure: true, sameSite: 'Strict' })`.
- For cookies set in Wix Velo frontend (page code or site code): note that HttpOnly cookies CANNOT be set from client-side JavaScript by design — move any sensitive cookie creation to a backend/Velo HTTP function.
- For third-party app cookies added via the Wix App Market: update each app to its latest version and contact the app developer if their cookie is flagged — Wix app partners are required to follow security standards.
- Contact Wix Support (Help Center → Contact Us) if a first-party Wix cookie is found missing flags, as these are outside owner control.
How to fix insecure cookie on Squarespace
- Squarespace-managed session and CSRF cookies are set by Squarespace's infrastructure. Ensure HTTPS is enabled: Settings → Advanced → SSL and set to 'Secure' (HTTPS only) with 'HSTS' toggled on.
- Squarespace does not expose server-side cookie configuration to store owners for platform cookies — if a Squarespace-native cookie is missing flags, report it via Squarespace Help → Contact Support.
- For cookies set via custom Code Injection (Settings → Advanced → Code Injection) or page Header/Footer code blocks: audit any `document.cookie` writes; append `; Secure; SameSite=Strict` to each. Note: HttpOnly cannot be set via client-side JS — remove sensitive cookie logic from injected scripts entirely.
- For cookies introduced by third-party extensions or connected services (e.g., Mailchimp popup, live chat): update the integration and check the vendor's documentation for cookie-security options.
How to fix insecure cookie on Webflow
- Webflow-managed cookies (including Webflow Memberships session cookies) are set server-side by Webflow. Ensure SSL is enabled: Project Settings → Hosting → SSL and publish to a custom domain with HTTPS.
- For the Webflow Memberships feature: session cookies are controlled by Webflow. Ensure you are on the latest Webflow plan and Memberships version; report missing flags via Webflow Support.
- For custom cookies set in Webflow custom code (Site Settings → Custom Code → Head/Footer, or Embed elements): audit all `document.cookie =` assignments; append `; Secure; SameSite=Strict`. Move any HttpOnly cookie creation to a backend service (e.g., a Cloudflare Worker or your own API) since JS cannot set HttpOnly.
- If using Webflow's Logic or integrations (e.g., Zapier, Make) that set cookies on your domain: review each integration for cookie security settings and update to latest versions.
- Use browser DevTools → Application → Cookies after publishing to verify all cookies carry the correct flags.
How to fix insecure cookie on Magento Open Source
- Follow the same steps as Adobe Commerce (Magento) above — Magento Open Source shares the same admin configuration paths.
- Navigate to Stores → Configuration → General → Web → Session Cookie Management and set 'Use Secure Cookie' = Yes, 'HTTP Only' = Yes.
- For SameSite on Magento Open Source 2.3.5+, set Cookie SameSite to 'Strict' in Stores → Configuration → General → Web → Default Cookie Settings.
- Run `bin/magento cache:flush` after saving configuration.
- Verify PHPSESSID and form_key cookies in DevTools show HttpOnly ✓, Secure ✓, SameSite = Strict.
How to fix insecure cookie on PrestaShop
- Go to Back Office → Advanced Parameters → Administration and ensure 'SSL enabled' and 'SSL on all pages' are both set to 'Yes'.
- Open config/defines.inc.php (via FTP/SSH or File Manager) and verify `define('_PS_SSL_ENABLED_', 1);` is set.
- For session cookie flags, edit config/config.inc.php or override in a custom module: call `session_set_cookie_params(['secure' => true, 'httponly' => true, 'samesite' => 'Strict'])` before `session_start()`.
- Alternatively, install a security hardening module from the PrestaShop Addons Marketplace (search 'security headers') that manages cookie flags through the module's configuration UI.
- Clear the PrestaShop cache (Advanced Parameters → Performance → Clear Cache) and verify flags in DevTools.
How to fix insecure cookie on OpenCart
- Open system/library/session.php and system/library/cart.php in your OpenCart installation (via FTP or Admin → Developer Tools if available).
- Find the `setcookie()` calls and add the flags: `setcookie($name, $value, ['expires' => time()+$expire, 'path' => '/', 'secure' => true, 'httponly' => true, 'samesite' => 'Strict']);`
- In config.php and admin/config.php, ensure `define('HTTPS_SERVER', 'https://...')` uses HTTPS.
- Search for any additional `setcookie()` calls in catalog/controller/startup/session.php and apply the same flags.
- Clear the OpenCart cache (Admin → Dashboard → blue cog icon → Refresh) and verify cookie flags in DevTools.
Does your site have this issue?
Run a free SEOLZ audit to find insecure cookie — and every other issue — across your whole site in minutes.
Scan my site freeFrequently asked questions
What is Insecure cookie?
Every time a visitor lands on your store, their browser receives small data files called cookies — one of which typically holds their login session or a CSRF token (a secret code that proves form submissions came from your real site, not an attacker). Each cookie can carry protective "flags" that tell the browser how to handle it safely. The three critical flags are: **HttpOnly** (JavaScript running on the page cannot read the cookie, so a hacked ad script cannot steal it), **Secure** (the browser only sends the cookie over HTTPS, never plain HTTP), and **SameSite=Strict** (the browser refuses to send the cookie when a request originates from a third-party site, blocking cross-site request forgery attacks). When any of these flags are missing, the cookie is left partially unprotected.
Why does insecure cookie matter?
A missing HttpOnly flag is the primary enabler of session-hijacking via Cross-Site Scripting (XSS): if even one ad, chat widget, or third-party script on your page is ever compromised, it can silently read your customers' session cookies and hand them to an attacker, who then logs in as that customer and sees their orders, saved addresses, and payment methods. A missing Secure flag risks cookies being transmitted in plain text if a customer ever hits an HTTP link, exposing their session to network eavesdroppers (especially on public Wi-Fi). A missing SameSite flag enables Cross-Site Request Forgery (CSRF), where a malicious page tricks a logged-in customer's browser into submitting unwanted actions — like changing their email or placing a fraudulent order — on your store. Beyond customer harm, a breach involving stolen session tokens can trigger PCI-DSS violations, GDPR fines, and lasting reputational damage that directly kills revenue.
How do I fix insecure cookie?
Set the HttpOnly, Secure, and SameSite=Strict flags on every session and CSRF cookie your store sets so they cannot be stolen by malicious scripts or sent over unencrypted connections.
Authoritative references
- OWASP Top Ten — OWASP
- OWASP Cheat Sheet Series — OWASP
- Secure Headers Project — OWASP
- Website security — MDN