Unsafe Cookie Flags — Session Cookies Too Easy to Steal or Replay

TL;DR: This check looks at the real cookies your page sets and asks a simple question: are they locked down well enough for a modern browser? If a session or auth cookie is missing Secure, HttpOnly, or a sensible SameSite setting, that cookie is easier to leak, replay, or send in the wrong context.

Modern browser guidance is clear on the basics: sensitive cookies should be sent only over HTTPS, session identifiers should usually not be readable by JavaScript, and cross-site cookie behaviour should be declared deliberately. This is not theory or “nice to have” hardening. It is part of the baseline hygiene that keeps login state, remember-me cookies, and preference cookies from being handled more loosely than you intended.

What Scavo checks (plain English)

Scavo inspects the live Set-Cookie headers returned by the exact URL it scanned. It does not guess from your framework or codebase. It checks what the browser would actually receive.

Scavo looks for:

• whether the scanned route is HTTPS
• how many cookies were set on that response
• whether cookies use Secure
• whether likely session/auth cookies use HttpOnly
• whether cookies declare SameSite
• whether any SameSite=None cookie is missing Secure
• whether __Secure- and __Host- cookie prefix rules are being broken

How Scavo scores this check:

• Info: the scanned route did not set any cookies, so there was nothing meaningful to score on that response
• Warning: cookies were set, but Scavo found weaker-than-recommended flags such as missing Secure, missing explicit SameSite, or a likely session cookie missing HttpOnly
• Fail: Scavo found higher-risk issues such as a session-like cookie missing Secure, a SameSite=None cookie without Secure, or a broken __Secure- / __Host- prefix rule
• Pass: observed cookies used solid baseline flags with no obvious prefix-rule violations

Scavo treats cookies as “session-like” when the name strongly suggests login or session state, for example session, sid, auth, token, jwt, remember, or secure-prefix cookie names.

How Scavo scores this check

Scavo assigns one result state for this check on the tested page:

• Pass: baseline signals for this check were found.
• Warning: partial coverage or risk signals were found and should be reviewed.
• Fail: required signals were missing or risky behavior was confirmed.
• Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.

In your scan report, this appears under What failed / What needs attention / What is working for cookie_security_flags, followed by Recommended next steps and Technical evidence (for developers) when needed.

• Scan key: cookie_security_flags
• Category: SECURITY

Why fixing this matters

Cookies are often where trust becomes state: signed-in sessions, remembered preferences, cart state, and consent choices all live here. If those cookies are too loose, you increase the chance of session theft, cross-site request abuse, or browser behaviour you did not mean to allow.

The practical problem is that cookie security usually drifts quietly. One route is behind HTTPS and sets strong flags, another is served by a different middleware path and sets a weaker cookie, and nobody notices until an audit or incident forces the issue.

Common reasons this check warns or fails

• A framework default is still setting cookies without an explicit SameSite value.
• Session or auth cookies are created before HTTPS enforcement is fully in place.
• Older code paths set cookies directly and bypass your normal session middleware.
• A SameSite=None cookie was added for embedded or cross-site use, but Secure was forgotten.
• A __Host- or __Secure- prefix was added for appearance, not with the actual prefix rules.

If you are not technical

1. Ask your developer for the actual live Set-Cookie headers from the route Scavo flagged. Config screenshots are not enough.
2. Ask whether the flagged cookies are login/session cookies, preference cookies, or third-party integration cookies.
3. Ask for a plain-English summary of what changed: which cookies were tightened, and why.
4. Re-run Scavo on the same URL and confirm the cookie list and flag warnings improve.

Scavo flagged Cookie Security Flags (cookie_security_flags). Please inspect the live Set-Cookie headers on the affected route, tighten Secure / HttpOnly / SameSite where appropriate, fix any __Secure- or __Host- prefix misuse, and share before/after response-header proof.

If you are technical

1. Inventory the cookies actually set on the flagged route, not just the cookies your framework usually sets.
2. Ensure any session, auth, remember-me, or token-like cookie is sent only over HTTPS with Secure.
3. Add HttpOnly to cookies that do not need to be read by frontend JavaScript.
4. Set SameSite deliberately. Lax is often a safe default for session cookies; None is only for genuine cross-site use and must also be Secure.
5. If you use __Secure-, make sure the cookie is actually Secure. If you use __Host-, make sure it is Secure, has Path=/, and does not set Domain.
6. Test login, logout, remember-me, checkout, and embedded flows after changes so you do not break intended cross-site behaviour.

How to verify

• Use browser devtools or curl -I on the exact route that sets the cookie.
• Confirm sensitive cookies include Secure and, where appropriate, HttpOnly.
• Confirm cookies declare SameSite intentionally instead of relying on guesswork.
• Confirm any SameSite=None cookie also includes Secure.
• Confirm __Host- cookies use Path=/ and omit Domain.
• Re-run Scavo and confirm cookie_security_flags improves on the same route.

What this scan cannot confirm

• It only sees cookies issued on the scanned response. A login POST, subdomain app route, or later JavaScript write may behave differently.
• It does not decide your product’s cross-site cookie strategy for you.
• It does not prove your session implementation is otherwise secure; it checks the cookie flags that were visible on this run.

Owner checklist

• [ ] Assign one owner for cookie policy at app/framework/edge level.
• [ ] Document which cookies are session, auth, preference, or third-party.
• [ ] Keep cookie defaults centralized so one route cannot silently drift.
• [ ] Re-test login and embedded flows after any SameSite change.

FAQ

Why would Scavo show Info instead of pass or fail?

Because not every page sets cookies. If the scanned response did not return any Set-Cookie headers, Scavo does not pretend it audited cookies that were not there.

Is missing HttpOnly always a bug?

No. Some frontend-readable cookies are intentional. The risk is mainly when session or auth cookies are readable by JavaScript even though they do not need to be.

Why is SameSite=None treated more strictly?

Because browsers expect SameSite=None cookies to be cross-site capable, and modern guidance requires them to also be Secure.

Are __Host- and __Secure- prefixes required?

Not always, but if you use them, you need to follow the real prefix rules. Otherwise the name suggests a security guarantee you are not actually meeting.

Sources

• MDN: Secure cookie configuration
• MDN: Set-Cookie header
• OWASP Session Management Cheat Sheet
• RFC 6265bis draft (HTTP State Management)

Need a clean cookie inventory and default policy per route type? Send support the flagged cookie names and the route where they are set.