Yoryantra
Home/Tools
← Back to Tools

Cookie Security Checker

Review Set-Cookie headers for common security issues. Check Secure, HttpOnly, SameSite, expiry, Domain, Path, cookie prefixes, Partitioned cookies, and risky settings in your browser.

Paste one or more Set-Cookie headers from a response, browser devtools, curl output, or an API gateway.

Options

Cookie checks are based on common browser security practices. Review changes before using them in production.

Output

Cookie security report will appear here.
Cookie checking happens directly in your browser. Your pasted headers are not uploaded to a server.

Checking Cookie Security Settings

Cookies often carry session IDs, login tokens, preferences, tracking values, and other browser state. A small mistake in a Set-Cookie header can make a cookie easier to steal, send cross-site, or expose to client-side scripts.

This Cookie Security Checker reviews Set-Cookie headers for common issues such as missing Secure, missing HttpOnly, weak SameSite settings, risky domain scope, long expiry, Partitioned cookie requirements, and prefix rule mistakes.

Reviewing a Set-Cookie Header

  1. Paste one or more Set-Cookie headers into the input box.
  2. Choose whether the cookies belong to HTTPS, HTTP, or local testing.
  3. Turn on checks for session cookies, SameSite, expiry, and suggested fixes.
  4. Run the checker and review warnings for each cookie.
  5. Copy the summary, detailed report, JSON, or suggested headers.

Common Cookie Security Checker Use Cases

  • Checking session cookies for Secure and HttpOnly flags.
  • Reviewing SameSite settings before deploying login flows.
  • Finding cookies that are scoped too broadly with Domain.
  • Checking __Host-, __Secure-, __Http-, and __Host-Http- cookie prefix rules.
  • Reviewing Partitioned cookies that must also use Secure.
  • Reviewing Set-Cookie headers from curl, devtools, or API responses.
  • Preparing safer cookie settings for web apps and APIs.

Example Secure Cookie

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

Cookie Security Depends on the App

A safe cookie setting depends on how the cookie is used. A session cookie usually needs stronger protection than a harmless preference cookie. A cross-site integration may need SameSite=None, but that also requires Secure.

Use this tool to catch common mistakes, then review the final header with your real login, API, JavaScript access, cross-site behavior, and browser support in mind.

Frequently Asked Questions

What does a Cookie Security Checker do?

It checks Set-Cookie headers for common security settings like Secure, HttpOnly, SameSite, Domain, Path, expiry, Partitioned cookies, and prefix rules.

Why is HttpOnly important?

HttpOnly helps prevent JavaScript from reading a cookie, which is especially important for session and authentication cookies.

Why does SameSite=None need Secure?

Browsers require SameSite=None cookies to also use Secure so they are only sent over HTTPS.

Should every cookie use Domain?

No. Omitting Domain usually keeps the cookie scoped to the exact host, which is often safer for sensitive cookies.

What should Partitioned cookies include?

Partitioned cookies must use Secure. For safer host scoping, a __Host- or __Host-Http- prefix is often a good fit when your app can use it.

Are my cookie headers uploaded anywhere?

No. Cookie checking happens directly in your browser.