Cookies Missing Security Flags
Cookies without Secure, HttpOnly, or SameSite flags can be stolen over plain HTTP, read by JavaScript, or used in CSRF attacks. Learn how to set them correctly.
What is this?
Every cookie your site sets is a small piece of data the browser stores and sends back with every subsequent request. Three attributes control how safely that happens: Secure tells the browser to only send the cookie over HTTPS, HttpOnly hides the cookie from JavaScript (so a compromised plugin can't read it), and SameSite controls whether the cookie is sent when a user clicks a link from another site. WordPress doesn't always set these by default — and if your PHP configuration or a plugin sets cookies without them, any one of the three gaps becomes a usable attack.
Why does it matter?
Without Secure, a session cookie set on the HTTPS version of your site can be leaked the instant a user accidentally loads any resource over plain HTTP — their session is now compromised. Without HttpOnly, any cross-site scripting (XSS) bug in any plugin gives an attacker direct access to the logged-in user's session cookie. Without SameSite, an attacker-controlled site can trigger requests to your site while the user is logged in, and the browser will obediently attach the session cookie — this is the core of a CSRF attack. Setting all three is a one-time config change that closes three common exploitation paths at once.
How to fix it
These steps are written for shared hosting (cPanel, Plesk, or similar). If you have direct server access, see the SSH section below.
Open Settings → MultiPHP INI Editor in cPanel (or equivalent), select your domain, and switch to Editor Mode.
Add or update these PHP directives:
session.cookie_secure = 1 session.cookie_httponly = 1 session.cookie_samesite = "Lax"
Note: If you don't have MultiPHP INI Editor, place these lines in a .user.ini file in your WordPress root directory instead.
Open File Manager and edit wp-config.php in your WordPress root. Add these lines near the top (before 'That's all, stop editing!'):
define('FORCE_SSL_ADMIN', true);
@ini_set('session.cookie_secure', 1);
@ini_set('session.cookie_httponly', 1);Save the file and log out / log in again so WordPress issues new cookies with the correct flags.
For developers / SSH access
Edit php.ini (find with: php --ini | grep Loaded):
session.cookie_secure = 1 session.cookie_httponly = 1 session.cookie_samesite = "Lax"
Restart PHP-FPM (adjust version to match):
sudo systemctl restart php8.1-fpm
Edit wp-config.php:
define('FORCE_SSL_ADMIN', true);For any cookies set outside of PHP (by nginx, a CDN, or a plugin), append the SameSite flag at the server level. In nginx:
proxy_cookie_path / "/; HTTPOnly; Secure; SameSite=Lax";
Note: If you use a caching plugin or CDN that sets its own cookies, check its settings for a 'Secure cookies' or 'SameSite' option.
How to verify the fix
Re-run your GuardingWP scan — the insecure_cookies finding should pass. You can also open your site in a browser, open DevTools (F12), go to the Application or Storage tab, and inspect the cookies. Each session cookie (wordpress_logged_in_*, PHPSESSID) should show ✓ under Secure, HttpOnly, and SameSite.
Re-run your scan to confirm this is resolved →Related issues
HTTP to HTTPS Redirect Missing
Visitors who type your address without 'https://' load the site over plain HTTP. Learn how to force every visitor onto the encrypted version.
Missing HTTP Security Headers
Your server isn't sending the HTTP headers that tell browsers how to protect your visitors. Learn which headers to add and how.
Login Page Exposed
Your WordPress login page is publicly accessible. Learn how to protect it from brute-force attacks.
Prefer to have this handled for you? Get this fixed — Medium ($89) →