How the cookies check works

Cookies are small pieces of data your site asks the browser to keep, such as a shopping basket or a login session. Three flags on each cookie decide how well it is protected. This check reads them.

What it reads

The Set-Cookie headers on your home page and up to two linked pages (a login or account page if the home page links to one). It reads the same pages as the security headers check, so it makes no extra requests. It never logs in, so it only sees cookies that are set before login.

What it reports

• Secure missing: on a site served over https://, a cookie without the Secure flag can also be sent over an insecure connection.
• HttpOnly missing: a cookie whose name looks like a session or login cookie (for example PHPSESSID, session, auth, token) can be read by scripts on the page. If a malicious script ever gets onto the page, it can steal the session. Cookies that scripts legitimately need, such as consent banners, are not flagged for this.
• SameSite missing: without SameSite=Lax or Strict, the cookie's behaviour when another site sends visitors to yours depends on the browser's default.

Each finding lists the cookie names, so your developer can find where they are set.

What it cannot see

• Cookies set after login, or only on pages the home page does not link to.
• Cookies created by scripts in the browser rather than sent by your server.
• Whether a cookie holds anything sensitive. The check judges by the flags and, for HttpOnly, by the name.

What to do with the result

The fix is usually one setting in your framework or CMS (for example the session cookie options in PHP, Laravel or WordPress plugins) or a cookie rule in the web server. Ask your developer to set Secure, HttpOnly where scripts do not need the cookie, and SameSite=Lax.