What are Cookie Security Flags?

Every time your WordPress site sets a cookie (whether for login sessions, shopping carts, analytics, or consent preferences), that cookie can carry a set of security flags. These flags tell the browser how to handle the cookie: when to send it, who can read it, and over which connections it may travel. Getting them wrong does not break anything visibly, but it opens the door to attacks that most site owners never notice until it is too late.

The Secure Cookie Flag: HTTPS-Only Cookies

A cookie with the Secure flag will only be transmitted over HTTPS connections. The browser simply refuses to include it in any unencrypted HTTP request.

Set-Cookie: session_id=abc123; Secure

Why does this matter? Picture a visitor accessing your site on a coffee shop Wi-Fi. If they happen to load a page over plain HTTP (maybe through an old bookmark or a redirect misconfiguration), their cookies would normally travel in cleartext across the network. Anyone sniffing that Wi-Fi traffic could grab the session cookie and impersonate the user. With the Secure flag, the browser holds the cookie back entirely in that scenario.

Since your WordPress site should be running on HTTPS anyway (and it should, there is no excuse in 2025), setting this flag costs nothing and prevents a real class of attacks.

The HttpOnly Cookie Flag: Protection Against XSS

The HttpOnly flag blocks JavaScript from accessing the cookie through document.cookie. The cookie still gets sent with HTTP requests as normal, but no client-side script can read or manipulate it.

Set-Cookie: session_id=abc123; HttpOnly

This flag exists specifically to limit the damage of Cross-Site Scripting (XSS) attacks. If an attacker manages to inject JavaScript into your page (through a vulnerable plugin, a comment field, or a stored XSS vector), one of the first things that script will try is document.cookie to steal session tokens. With HttpOnly in place, that call returns nothing for the protected cookies.

It does not prevent XSS itself. It does not fix the underlying vulnerability. But it takes the most valuable prize (session cookies) off the table, which often makes the difference between a nuisance and a full account takeover.

The SameSite Cookie Flag: CSRF Protection

The SameSite attribute controls cross-site cookie behavior. It determines whether the browser sends a cookie when a request originates from a different domain than the one that set it.

There are three possible values:

• SameSite=Strict: The cookie is never sent with cross-site requests. Period. If someone clicks a link to your site from an external page, their session cookie will not be included in that first request. This is the most restrictive setting and can cause usability issues (users appear logged out when arriving from external links).
• SameSite=Lax: The cookie is sent with top-level navigations (clicking a link) but not with embedded requests like images, iframes, or form submissions from other sites. This is the browser default since Chrome 80 (2020) and provides a good balance between security and usability.
• SameSite=None: The cookie is sent with all requests, regardless of origin. This is needed for legitimate third-party cookie use cases (embedded payment forms, SSO, advertising), but it must always be combined with the Secure flag, since browsers reject SameSite=None without Secure.

Set-Cookie: session_id=abc123; SameSite=Lax

The main threat SameSite addresses is Cross-Site Request Forgery (CSRF), attacks where a malicious site tricks your browser into making authenticated requests to your WordPress site without your knowledge.

Recommended Secure Cookie Configuration

For authentication and session cookies, the recommended configuration is:

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

Each flag covers a different attack vector:

• Secure: stops network-level interception
• HttpOnly: stops script-level theft (XSS)
• SameSite: stops cross-origin abuse (CSRF)

Missing any one of them leaves a gap. They work as a team.

Third-Party Cookie Security and GDPR

Cookies set by external services loaded on your site (analytics, chat widgets, advertising pixels) are out of your direct control. Their security flags are determined by the service that sets them. But you should be aware of them. A third-party cookie without Secure or with SameSite=None creates exposure on your domain, even though you did not set the cookie yourself.

This is especially relevant for GDPR compliance: knowing which cookies are set on your site and how they are configured is part of your responsibility as the site operator.

Audit Your Cookie Security Flags with InspectWP

InspectWP examines every cookie set during a page load on your WordPress site and flags those missing the Secure, HttpOnly, or SameSite attributes. The report shows each cookie with its current flags, so you can quickly see which ones need attention, whether they come from WordPress core, plugins, or third-party scripts.