Loading…
Loading…
Cookies and privacy
We use strictly necessary cookies to run the site. With your permission we also load Vercel Web Analytics and Speed Insights to measure traffic and performance in aggregate. See our Cookie Policy and Privacy Policy.
Paste any URL you're authorized to test. Scorifya parses every Set-Cookie response header and reports each cookie's Secure, HttpOnly, and SameSite attributes.
Free tool
Session cookies that travel without Secure leak on the first plaintext hop. Cookies without HttpOnly are readable by any XSS — yours or a third-party SDK's. SameSite=None without Secure is rejected outright by modern browsers. The cookie inspector surfaces these problems by parsing every Set-Cookie header your site issues on the URL you submit.
Paste any URL you're allowed to test. Scorifya fetches the response, parses every Set-Cookie header, and reports each cookie's name, scope, and protective attributes (Secure, HttpOnly, SameSite). Session cookies missing required attributes get flagged with the specific risk they carry. Cookies sit inside the broader 0–100 hardening score.
This page is written for people searching for cookie inspector—same tool as the homepage, with context for that query.
How we differ from deep TLS graders, browser-focused posture tools, and header-only checkers: read the comparison.
Illustrative snapshots of what a report can look like—paste your URL above for a live score on your site.
Example A — session cookie missing Secure
TLS works, but a session cookie is set without Secure. On any plaintext hop (mixed content, dev tooling, redirect typo), the cookie travels in clear.
Session cookie missing Secure
Mark every authentication cookie Secure so it's only sent over TLS. See /checks/session_cookie_missing_secure.
Session cookie missing HttpOnly
Without HttpOnly, the cookie is readable by document.cookie. Any XSS can exfiltrate it.
SameSite attribute not set
Browsers default to Lax for unset cookies, but explicit SameSite=Lax (or Strict) tightens the contract.
Example B — fully protected session cookie
Session cookie has Secure, HttpOnly, and SameSite=Lax. Other categories carry the remaining gap.
Permissions-Policy missing
A short Permissions-Policy denying camera/microphone/geolocation tightens the browser-feature contract.
Mark every authentication cookie Secure + HttpOnly
These two attributes together prevent the most common token-theft paths. There's no production reason to omit either.
Default SameSite to Lax (or Strict)
SameSite=Lax is the modern default. Use Strict if you don't need cross-site navigation to keep the user logged in. Reserve SameSite=None for cookies that genuinely need cross-site delivery — and pair it with Secure.
Avoid SameSite=None without Secure
Modern browsers reject this combination outright. If your cookie ever needs cross-site delivery, set both attributes together.
Scope cookies tightly
Avoid setting Domain on session cookies unless you actively need subdomain sharing. Domain-less cookies are scoped to the issuing host only.
Re-scan after auth-flow changes
Session cookie attributes are framework-driven. After a framework upgrade or auth-library swap, re-scan to confirm the attributes still pass.
For weights and penalties behind each category, see How Scorifya works.
Secure, HttpOnly, SameSite, and Domain scope. Scorifya parses every Set-Cookie header on the response and reports per-cookie status.
No. Scorifya only inspects Set-Cookie headers on unauthenticated public responses. Cookies set during a login flow have to be tested with your own staging tools or a session-aware scanner.
Edge cases still hit plaintext: mixed-content subresources, dev/staging configs, redirect typos. Secure ensures the cookie never leaves TLS regardless of those paths.
CSP blocks most XSS execution paths, but a small percentage still get through (especially via third-party SDKs). HttpOnly is the cheap defense-in-depth that prevents successful XSS from reading the cookie at all.
No. Cookies set client-side via document.cookie don't appear in Set-Cookie response headers. The inspector only sees what the server set.
More detail on limits and billing: FAQ.
TLS, HTTPS & redirects
Valid certificates, modern TLS, and clean HTTP→HTTPS upgrades. We also probe whether legacy TLS 1.0/1.1 are still accepted.
Security headers
CSP, HSTS, and related headers reduce common browser-side attack surfaces and clickjacking risk.
DNS & email (passive)
SPF, DMARC, a few DKIM selectors, MX, and whether common subdomains resolve publicly—without port scanning.
Hygiene signals
Verbose server banners and risky defaults can raise your attack surface and erode trust.
Not a vulnerability scan
Scorifya checks public configuration signals; it does not attempt exploitation, port scans, or authenticated crawling.
If you're iterating on headers or deploying changes, you'll likely run multiple checks as you tighten config. When you're ready, Scorifya Pro removes scan limits and unlocks JSON/CSV/PDF exports.