Cookies are missing security flags

SeverityMedium

ScopeWhole site

EffortMedium

Verified bySecurity scan (weekly, or Re-scan)

Rule keysec_cookie_flags

Short answer

Every cookie served over HTTPS should carry Secure so it is never sent over plain HTTP. Session and login cookies also need HttpOnly so JavaScript cannot read them, and SameSite=Lax (or Strict) limits when the browser attaches them to requests started by other sites. In WordPress, PHP and most frameworks these are settings, not code changes. There is no ranking effect.

Why it matters

A cookie without Secure is sent in clear text whenever the browser makes an http:// request to your domain, for example through an old link or on a hostile Wi-Fi network that forces one, and anyone on that network can copy it. A session cookie without HttpOnly can be read by any script on the page, so a single cross-site scripting bug or a compromised third-party script turns into account takeover. SameSite is the browser's built-in defence against cross-site request forgery.

A copied session cookie works like the user's password for as long as the session lasts, including for administrator accounts.

How Glimana detects it

Glimana reads the Set-Cookie headers an anonymous visitor receives on your home page and up to two other pages (one of your important pages and the most recently updated page in your sitemap). A cookie is flagged when it lacks Secure; when its name looks like a session or login cookie (it contains sess, auth, token, login or remember, or is PHPSESSID, laravel_session, JSESSIONID and similar) and lacks HttpOnly; when SameSite has an invalid value; or when SameSite=None comes without Secure. CSRF cookies such as XSRF-TOKEN are not expected to be HttpOnly. The problem is Medium when a session-type cookie is affected and Low otherwise; with no cookies at all the check is Not applicable. A missing SameSite alone is not flagged, and cookies that are only set after login are not seen.

How to fix it

Watch out

Do not add HttpOnly to cookies your own JavaScript must read, such as consent-banner or CSRF cookies; they will stop working. SameSite=Strict on the session cookie makes users appear logged out when they arrive from an e-mail link or return from a payment or single sign-on page; use Lax unless you need Strict. Browsers accept SameSite=None only together with Secure.

Find the finding in Glimana. Open Security; this check is in the Cookies and cross-site access group, with the evidence from the last scan under its title. The same problem is listed under Issues › Cookies are missing security flags.
Apply the fix on your platform.

WordPressPHP / LaravelApache / Nginx

WordPress core sets its login cookies with HttpOnly, and with Secure when it detects HTTPS. If core cookies are flagged, make sure both addresses under Settings › General start with https://. Behind a proxy or Cloudflare's Flexible SSL mode WordPress may not detect HTTPS; switch Cloudflare to Full (strict) or, behind your own proxy, add if (($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https') { $_SERVER['HTTPS'] = 'on'; } to wp-config.php. Most flagged cookies come from plugins (analytics, consent, chat, A/B testing): the cookie name in the issue tells you which one, so update it or check its settings.

PHP sessions, in php.ini or .user.ini where your host allows it: session.cookie_secure = 1, session.cookie_httponly = 1, session.cookie_samesite = Lax. Cookies you set yourself: setcookie('name', $value, ['secure' => true, 'httponly' => true, 'samesite' => 'Lax', 'path' => '/']);. Laravel: in .env set SESSION_SECURE_COOKIE=true and SESSION_SAME_SITE=lax, then run php artisan config:cache; http_only is already true in config/session.php.

Fixing the application is better, but a server rule can add the flag to every cookie. Apache (mod_headers), both lines, because the right one depends on how PHP runs: Header always edit Set-Cookie "(?i)^((?:(?!;\s*secure).)+)$" "$1; Secure" and Header edit Set-Cookie "(?i)^((?:(?!;\s*secure).)+)$" "$1; Secure". Nginx in front of an application (1.19.3 or later), in the proxying location: proxy_cookie_flags ~ secure samesite=lax;. Neither reaches cookies that JavaScript sets in the browser.
Check it in Glimana. Press Re-scan on the Security page (up to two scans an hour) or wait for the weekly scan on Sunday; the problem closes when the check passes.

How the fix is verified

After fixing, press Re-scan on the Security page (or wait for the weekly Sunday scan); the problem closes as soon as the check passes.