Insecure cookie
Moderate effortSet the HttpOnly, Secure, and SameSite flags on all session and authentication cookies to prevent them from being stolen or misused by attackers.
What it is
Every cookie your store sets can carry optional security flags that tell the browser how to protect it. The three most important are: *HttpOnly* (JavaScript on the page cannot read the cookie — so a malicious script injected into your site cannot steal it), *Secure* (the cookie is only ever sent over HTTPS, never plain HTTP), and *SameSite* (the cookie is not sent along with cross-site requests, blocking a class of attack called Cross-Site Request Forgery, or CSRF). A cookie missing any of these flags is being sent to your customers' browsers without those protections in place.
Why it matters
Without HttpOnly, a single piece of injected JavaScript — from a compromised ad, a third-party widget, or an XSS vulnerability anywhere on your site — can silently read your customers' session cookies and hand them to an attacker, who then logs in as that customer and takes over their account. Without Secure, the cookie can leak over unencrypted connections. Without SameSite, attackers can craft malicious pages that silently submit requests to your store as a logged-in customer (CSRF). Together, insecure cookies are one of the most common ways ecommerce accounts get hijacked, leading to fraudulent orders, leaked personal data, and regulatory liability under laws like GDPR and PCI-DSS. OWASP ranks this entire class of flaws as A07:2021 — Identification and Authentication Failures.
How to fix it
- Audit every cookie your store sets — use browser DevTools (Application → Cookies) to list all cookies and note which ones are missing HttpOnly, Secure, or SameSite.
- For cookies set by your own application or theme code, add the missing flags directly in the code that creates the cookie (see platform steps below).
- For cookies set by your web server or platform middleware (e.g. session cookies), configure the server or framework to apply all three flags globally rather than cookie-by-cookie.
- For third-party cookies (analytics, chat, payment widgets), check the vendor's documentation — you usually cannot add flags to cookies you do not set, but you can request the vendor enable them, or isolate those scripts.
- Re-check with browser DevTools after deploying changes to confirm all session/auth cookies now show HttpOnly ✓, Secure ✓, and SameSite=Strict (or Lax) ✓.
- Add the Set-Cookie header check to your deployment checklist or use an automated security scanner to catch regressions.
Fix it on your platform
Pick your platform for the exact steps.
How to fix insecure cookie on Shopify
- Shopify manages its own session cookies (e.g. _shopify_y, _shopify_s) internally and applies Secure and SameSite=Lax by default — you cannot modify these directly.
- For the XSRF-TOKEN cookie specifically: Shopify sets this cookie for its own CSRF protection. If a scanner flags it as missing HttpOnly, note that XSRF tokens are intentionally readable by JavaScript (that is how CSRF protection works). The real concern is the Secure and SameSite flags. Open your theme's Shopify admin: Online Store → Themes → Edit code.
- If your theme or a custom app sets any cookies via JavaScript (e.g. in a .js asset file or a <script> tag in a .liquid file), locate that code and switch from document.cookie = 'name=value' to a server-side Set-Cookie header (via a Shopify App Proxy or a custom app's backend) so you can add the flags properly.
- For any custom Shopify app backend (Node/Ruby/Python), set cookies using your framework's cookie helper with { httpOnly: true, secure: true, sameSite: 'Strict' } (see code snippets).
- Verify in Chrome DevTools → Application → Cookies → your store domain that all auth/session cookies show the correct flags.
How to fix insecure cookie on Shopify Plus
- Follow all standard Shopify steps above.
- For Shopify Plus storefronts using custom checkout (checkout.liquid or Checkout Extensibility), any server-side cookies set in checkout scripts must be configured in your custom app or checkout extension backend with httpOnly: true, secure: true, sameSite: 'Strict'.
- If you use Shopify Plus Scripts or a third-party headless front-end, audit cookies set by that layer and add flags at the server/CDN edge (e.g. via Cloudflare Workers or Vercel Edge Middleware).
How to fix insecure cookie on WooCommerce
- Install the 'Headers & Cookies Security' plugin (e.g. 'WP Headers and Cookies' or 'Sucuri Security') to apply secure cookie flags globally without editing code.
- Alternatively, add the following to your theme's functions.php or a custom plugin (see code snippet): use session_set_cookie_params() before session_start() with httponly=true, secure=true, samesite=Strict.
- For the WordPress session cookie (wordpress_logged_in_*, wordpress_sec_*), add a filter in functions.php using add_filter('auth_cookie_expiration', ...) — but more directly, add ini_set and session_set_cookie_params as shown in the code snippet.
- In your wp-config.php ensure FORCE_SSL_ADMIN is set to true: define('FORCE_SSL_ADMIN', true);
- Go to WP Admin → Settings → General and ensure both WordPress Address and Site Address use https://.
- Verify flags in browser DevTools → Application → Cookies.
How to fix insecure cookie on BigCommerce
- BigCommerce manages core session cookies (SHOP_SESSION_TOKEN, etc.) at the platform level — contact BigCommerce support if the scanner flags their own cookies, as these are set server-side by the platform.
- For cookies set by your custom Stencil theme JavaScript, move cookie creation to a server-side API route (BigCommerce App or serverless function) and set flags there.
- For a custom BigCommerce headless/Next.js storefront, set cookies in your API routes using response.setHeader('Set-Cookie', 'name=value; HttpOnly; Secure; SameSite=Strict').
- Navigate to BigCommerce Admin → Storefront → Script Manager and review any third-party scripts that might set cookies; contact those vendors to enable secure flags.
- Verify in browser DevTools → Application → Cookies.
How to fix insecure cookie on Adobe Commerce (Magento)
- Log in to the Magento Admin Panel.
- Go to Stores → Configuration → General → Web → Session Validation Settings and enable 'Use HTTP Only' = Yes.
- Go to Stores → Configuration → General → Web → Default Cookie Settings: set 'Cookie HttpOnly' = Yes, 'Cookie Secure' = Yes (requires HTTPS), 'Cookie SameSite' = Strict.
- For session cookies, also check app/etc/env.php or app/etc/config.php for session configuration and set 'cookie_httponly' => 1, 'cookie_secure' => 1, 'cookie_samesite' => 'Strict'.
- Run bin/magento cache:flush after making config changes.
- Verify with browser DevTools → Application → Cookies that frontend and adminhtml cookies show all three flags.
How to fix insecure cookie on Magento Open Source
- Follow the identical steps as Adobe Commerce above — the Stores → Configuration paths are the same.
- Additionally edit app/etc/env.php to set cookie flags at the PHP session level as a backstop (see code snippet).
- Run bin/magento setup:upgrade && bin/magento cache:flush.
How to fix insecure cookie on Wix
- Wix controls its own session cookies at the platform level — you cannot directly modify their flags. If the scanner flags Wix-owned cookies (e.g. svSession), report this to Wix support; these are managed by Wix infrastructure.
- For cookies set via Wix Velo (formerly Corvid) backend code, use the wixSession API or set cookies in a Wix HTTP Functions response: response.cookies = { name: { value: '...', httpOnly: true, secure: true, sameSite: 'Strict' } };
- In Wix Editor: open Dev Mode (top bar → Dev Mode → Enable), then open Backend → http-functions.js to add/modify cookie-setting code.
- Review any third-party apps installed from the Wix App Market that set cookies and contact vendors to confirm secure flags are in use.
How to fix insecure cookie on Squarespace
- Squarespace manages all core session cookies at the platform level — you cannot modify their Set-Cookie headers directly. If core cookies are flagged, raise the issue with Squarespace support.
- For any custom cookies set via Code Injection (Settings → Advanced → Code Injection) or page-specific JavaScript blocks, refactor those cookies to be set server-side instead. Because Squarespace does not offer server-side scripting, move cookie logic to an external serverless function (Netlify Functions, Vercel, Cloudflare Workers) and proxy the response.
- Audit third-party scripts added via Code Injection and remove or replace those that set insecure cookies.
How to fix insecure cookie on Webflow
- Webflow manages its own session cookies at the platform level — contact Webflow support for flags on cookies set by Webflow itself.
- For cookies set in custom JavaScript (via Webflow's Embed blocks or Project Settings → Custom Code), move cookie creation to a serverless backend (e.g. Cloudflare Workers, Netlify Functions) and set the Set-Cookie response header with all three flags there.
- In Webflow Designer: go to Project Settings → Custom Code and audit any document.cookie assignments in <script> blocks; remove them and replace with a server-side approach.
- If using Webflow Memberships (beta/released), test login cookies in DevTools and report missing flags to Webflow support.
How to fix insecure cookie on WordPress.org
- Add the following code to your theme's functions.php or a site-specific plugin to harden WordPress cookie settings (see PHP code snippet below).
- Install a dedicated security plugin such as Wordfence, iThemes Security, or Solid Security — each has a 'Secure Cookies' or 'Cookie Security' toggle in their settings dashboard.
- With Wordfence: go to WP Admin → Wordfence → All Options → Login Security → enable 'Enforce secure cookies'.
- With Solid Security (iThemes): go to Security → Settings → System Tweaks → enable 'Secure Socket Layers / SSL' and 'Disable File Editing'.
- Ensure HTTPS is active (SSL certificate installed) before setting Secure flag — cookies flagged Secure are silently dropped over HTTP.
- Verify in browser DevTools → Application → Cookies.
How to fix insecure cookie on PrestaShop
- Open config/config.inc.php and locate or add session cookie configuration.
- In the PrestaShop back office: go to Advanced Parameters → Administration → and enable 'SSL' and 'SSL on all pages' (requires SSL certificate).
- Edit config/defines.inc.php or override the cookie class to set httponly and secure flags: in classes/Cookie.php (or an override), ensure __construct passes httponly=true and secure=true to setcookie().
- For a cleaner approach, create a file override/classes/Cookie.php and override the constructor to always set these flags.
- Clear the PrestaShop cache: Advanced Parameters → Performance → Clear cache.
- Verify with browser DevTools.
How to fix insecure cookie on OpenCart
- Open system/library/session/native.php (or the relevant session handler for your version).
- Find the session_set_cookie_params() call and update it to include httponly: true, secure: true, samesite: 'Strict' (see PHP snippet).
- Alternatively edit index.php in the root and add session_set_cookie_params() before session_start().
- Save the file and test in browser DevTools → Application → Cookies.
How to fix insecure cookie on Headless / Custom (I build in code)
- In Node.js/Express: use res.cookie('name', value, { httpOnly: true, secure: true, sameSite: 'strict' }) or configure express-session with { cookie: { httpOnly: true, secure: true, sameSite: 'strict' } }.
- In Python/Django: set SESSION_COOKIE_HTTPONLY = True, SESSION_COOKIE_SECURE = True, SESSION_COOKIE_SAMESITE = 'Strict' in settings.py.
- In Python/Flask: configure app.config with SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SECURE=True, SESSION_COOKIE_SAMESITE='Strict'.
- In PHP: call session_set_cookie_params(['httponly'=>true,'secure'=>true,'samesite'=>'Strict']) before session_start(), or pass flags to setcookie().
- At the CDN/reverse-proxy layer (Nginx, Cloudflare, Vercel): add a response header transformation to inject missing flags as a universal backstop.
- Re-run your security scanner or check DevTools after deployment to confirm all session cookies show the three flags.
Does your site have this issue?
Run a free SEOLZ scan 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 cookie your store sets can carry optional security flags that tell the browser how to protect it. The three most important are: **HttpOnly** (JavaScript on the page cannot read the cookie — so a malicious script injected into your site cannot steal it), **Secure** (the cookie is only ever sent over HTTPS, never plain HTTP), and **SameSite** (the cookie is not sent along with cross-site requests, blocking a class of attack called Cross-Site Request Forgery, or CSRF). A cookie missing any of these flags is being sent to your customers' browsers without those protections in place.
Why does insecure cookie matter?
Without HttpOnly, a single piece of injected JavaScript — from a compromised ad, a third-party widget, or an XSS vulnerability anywhere on your site — can silently read your customers' session cookies and hand them to an attacker, who then logs in as that customer and takes over their account. Without Secure, the cookie can leak over unencrypted connections. Without SameSite, attackers can craft malicious pages that silently submit requests to your store as a logged-in customer (CSRF). Together, insecure cookies are one of the most common ways ecommerce accounts get hijacked, leading to fraudulent orders, leaked personal data, and regulatory liability under laws like GDPR and PCI-DSS. OWASP ranks this entire class of flaws as A07:2021 — Identification and Authentication Failures.
How do I fix insecure cookie?
Set the HttpOnly, Secure, and SameSite flags on all session and authentication cookies to prevent them from being stolen or misused by attackers.
Authoritative references
- OWASP Top Ten — OWASP
- OWASP Cheat Sheet Series — OWASP
- Secure Headers Project — OWASP
- Website security — MDN