Attribute checked first in cookie analysis
Secure is an attribute for sending cookies only for HTTPS communication. HttpOnly suppresses references from JavaScript and reduces the risk of cookie theft when XSS occurs. SameSite controls the extent to which cookies are sent for cross-site requests.
Cookies that omit Domain are limited to the host that set them. If you specify a Domain, it will be shared to subdomains, so it is important not to expand it more than necessary. Path is not a security boundary, but it allows you to organize what you send.
| Attributes | Main role | Check points |
|---|---|---|
| Secure | Send only via HTTPS communication | Generally valid for authentication/session cookies |
| HttpOnly | Suppress references from JavaScript | Valid for authentication cookies that do not use values on the screen |
| SameSite | Control cross-site sending | Clarify Lax, Strict, None according to the purpose |
| Domain | Specify the destination host | If unnecessary, omit it and limit it to the host. |
| Path | Specify the transmission target path | Check if the beginning is / and matches the expected path |
| Expires / Max-Age | Specify persistence period | Minimum necessary, if you have both, give priority to Max-Age |
How to parse Cookie and Set-Cookie
- Paste the Set-Cookie line, Cookie line, or complete set of HTTP headers into the input field.
- If the automatic judgment makes a mistake, explicitly select the input format.
- If you want to check the consistency with Domain, Path, and HTTPS, enter the criteria URL.
- Perform analysis and check causes and countermeasures for each critical, warning, and caution category.
- Copy or save the report with the values masked and reparse the modified headers.
Notes on SameSite/Partitioned/Cookie prefix
SameSite=None allows cross-site sending and must be used with Secure. Partitioned cookies also require Secure and check third-party context usage and supported browsers.
Cookies starting with __Secure- require Secure. __Host- further requires Path=/ and Domain not specified, allowing you to express strong settings limited to the entire host. If the name does not meet the requirements, the cookie will be rejected.
Share your diagnostic results securely
Cookie values may include session IDs, JWTs, access tokens, etc. Please enable the value mask on the screen and make it a standard state that the actual value is not included in the report.
Although this tool processes input within the browser, you should also be careful about copying input sources, screen sharing, and report management after saving. Do not attach reports containing actual values to tickets or chats.
Diagnostics is an adjunct to configuration review. Be sure to check server implementation, CSRF/XSS countermeasures, session expiration, and actual operation with supported browsers.
Specific example: Reviewing the Set-Cookie header for authentication cookies
A cookie called auth_token is set in the response of the login process. While the value is long enough, only Path is specified and Secure, HttpOnly, and SameSite are missing. If this continues, there may be insufficient protection for the intended use.
If you enter the Set-Cookie header and the actual source URL, it will be treated as an authentication cookie name, and any missing attributes and URL/scope consistency will be displayed. Don't just adopt the recommended example; instead, check whether cross-site usage is necessary and then reflect it in the server settings.
- Get the Set-Cookie header from your browser's developer tools or server logs.
- Enter the header and, if necessary, enter the HTTPS URL where you want to set cookies in the judgment criteria URL.
- Read the reasons in order of Critical, Warning, Caution, and check Secure, HttpOnly, SameSite, Domain, and Path.
- Compare the recommended Set-Cookie example with your actual requirements, correct and double-check the settings on the server side.
Cookie values may include authentication information. Please hide the values in the shared report, and limit the setting to include the actual values for local use only.
Frequently asked questions
- Can I automatically read cookies stored in my browser?
- Cookies from arbitrary sites and HttpOnly cookies cannot be automatically acquired due to browser security restrictions. Paste and parse the cookie or Set-Cookie header of interest.
- Can I check Secure or SameSite with just the cookie header?
- Unable to confirm. Only the name and value are sent in the cookie header of the request, no attributes. Use the Set-Cookie header in the response.
- If the diagnostics show no problems, are cookies completely safe?
- We do not guarantee complete safety. Please also check CSRF countermeasures, XSS countermeasures, session management, expiration processing, HTTPS settings, and how to generate cookie values.
Try It in Your Browser
Your input is processed entirely in your browser. Keep the original data, review the output, and only then save or share it.
Open cookie analysis/security diagnostic tool