HttpOnly checker: how to verify whether cookies are protected from JavaScript

If you searched for an HttpOnly checker, you are usually trying to answer one practical question: can JavaScript read a sensitive cookie in the browser. The HttpOnly attribute helps protect session cookies by preventing access through document.cookie, which reduces the impact of common XSS mistakes. It is not a full security strategy on its own, but it is a baseline hardening control worth checking regularly.

What an HttpOnly checker should show

A useful HttpOnly checker should do more than confirm that cookies exist. It should clearly show, per cookie:

• Cookie name and domain.
• Whether HttpOnly is set (Yes/No).
• Related attributes like Secure and SameSite.
• Context about why that cookie exists and whether it appears before consent.

That gives engineering and security teams a shared, auditable view of cookie behavior instead of manual guesswork from scattered browser sessions.

How to interpret the result

Seeing HttpOnly: Yes is generally positive for authentication and server-managed session cookies. Seeing HttpOnly: No is not always a bug, because some client-side features intentionally use JavaScript-readable cookies. The key is purpose: sensitive session identifiers should usually be HttpOnly, while low-risk preference or state values may be readable when intentionally designed that way.

Using PrivacyProbe as an HttpOnly checker

PrivacyProbe now includes HttpOnly visibility directly in the output cookie list so teams can review this attribute without leaving the report workflow. You can run a scan from the PrivacyProbe homepage, then inspect each cookie row for its HttpOnly status.

This is especially useful during release checks, consent banner updates, or third-party script changes when cookie behavior can drift quietly over time.

Practical checklist

1. Scan key production URLs and login flows.
2. Review cookies that look like session or auth identifiers first.
3. Confirm those sensitive cookies are marked HttpOnly and Secure where appropriate.
4. Document intentional exceptions so future reviews are faster.
5. Re-check after major frontend or tag-manager changes.

An HttpOnly checker is most valuable when it is part of a repeatable process. Short, frequent checks create fewer surprises than one-off audits after an incident.