OneWebDesk

Cookie Security Check

Check Secure, HttpOnly and SameSite flags on response cookies.

Cookie Security Check fetches the Set-Cookie headers a website sends to the browser and inspects whether each cookie carries proper security attributes such as Secure, HttpOnly and SameSite. It helps you quickly tell whether session cookies or login tokens are exposed to theft or tampering.

Just enter a URL and the server safely requests the page and analyzes the cookies in the response headers. The cookie values themselves are not used for judgment — only whether key attributes are present, shown as an OK or warning status. Results are briefly cached for speed.

Three core security attributes

  • Secure: sends the cookie only over HTTPS. Without it, the cookie can leak over plain HTTP and is vulnerable to man-in-the-middle attacks. Essential for login and session cookies.
  • HttpOnly: blocks JavaScript (document.cookie) from reading the cookie, making session theft far harder even if an XSS flaw exists.
  • SameSite: controls whether the cookie is sent on requests from other sites. Strict/Lax greatly reduce CSRF risk, while None must always be paired with Secure.

How to read the results

For each cookie, Secure and HttpOnly being set is shown as OK, and missing as a warning. The SameSite value (Strict/Lax/None) is shown too. For sensitive auth cookies, treat Secure + HttpOnly + SameSite=Lax (or Strict) as the recommended baseline, and check that the domain, path and expiry (Expires/Max-Age) are not broader than intended. Alongside cookies, run the security headers checkerto review response headers like HSTS and CSP and gauge the site's baseline protection in one pass.

Frequently asked questions

I don't see any cookies.
If the page sends no Set-Cookie header in its response, there are no cookies to inspect. Many sites set cookies only after login or on specific paths.
How do SameSite=Lax and Strict differ?
Strict sends the cookie on no cross-site-initiated request, making it the safest, but it can hurt usability — users arriving from an external link may appear logged out. Lax still sends the cookie on top-level navigations (link clicks), so for most authentication cookies Lax is the sweet spot between security and usability.
Is a missing Secure flag always dangerous?
For session or auth cookies it is a red flag. For non-sensitive analytics cookies the impact may be smaller, but on an HTTPS site enabling Secure is still recommended.
Is SameSite=None a bad setting?
It is legitimate when cross-site use is required (e.g. payments or embeds). However None must be paired with Secure, or modern browsers will reject the cookie.
Are my URL or cookie values stored?
Cookie values are never used for judgment, sent elsewhere, or stored permanently. Only the check result is cached briefly (about 60 seconds) to reduce load.

Related tools

Web Security