Set Secure, HttpOnly and SameSite on session cookies, give them the shortest useful lifetime, and scope them to the narrowest domain and path. These settings reduce session theft through cross site scripting and limit cross site request abuse on carts and accounts.
What each attribute does
MDN's guidance on secure cookie configuration says to limit access to cookies as much as possible, because cookies often carry session identifiers or other sensitive information. Its recommendations:
| Attribute | What it does |
|---|---|
| Secure | Cookie is sent only over HTTPS |
| HttpOnly | Hides the cookie from JavaScript, which helps stop an XSS bug from stealing a session ID |
| SameSite Strict or Lax | Limits sending the cookie on requests from other sites, a partial defense against CSRF, clickjacking and some cross site leaks |
| Expires or Max-Age | Cookies should expire as soon as no longer needed |
| Domain | Use the most restrictive domain possible |
| Path | Use the most restrictive path possible |
The MDN page says to set HttpOnly on all cookies that do not need JavaScript access, and in particular on session identifier cookies.
Why it matters for a store
A session cookie is the key to a logged in account with saved addresses and order history. A cart cookie tied to a session can be abused if another site can trigger requests on a buyer's behalf. If third party scripts run on your pages, an HttpOnly session cookie is a barrier they cannot read directly.
Steps to check your cookies
- Open your store in a private browser window, sign in, and open the browser's storage tool.
- List cookies for your domain and note which are session, cart, preference and tracking cookies.
- For each session or login cookie, confirm Secure, HttpOnly and SameSite are present.
- Check that no sensitive value, such as a plain customer ID or email, sits in a cookie readable by scripts.
- Check lifetimes. A login cookie that lasts a year deserves a second look.
- Set the attributes in your platform or server configuration, then test again after the change.
Limits to remember
SameSite is described as a partial defense, so keep other controls such as anti forgery tokens on state changing requests. HttpOnly stops direct reading, but a script running on the page can still make requests as the user, so it does not replace fixing XSS.
Quick check
Does HttpOnly stop all XSS damage?
No. It prevents reading the cookie from JavaScript, but injected script can still act within the page.
Should every cookie be HttpOnly?
Set it on all cookies that do not need JavaScript access, per MDN. Some preference cookies may need script access.
Sources
Safeguard's DAST scanning can check web apps you own for common misconfigurations, and the free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
