__Secure- cookie misconfiguration
__Secure- cookie misconfiguration: what it means, why it may matter, and how to remediate with external verification using ExposureGrid.
The problem
__Secure- cookie misconfiguration: Browser cookies often carry session and CSRF state. Weak flags or scope can increase the impact of network and XSS-style issues.
Why it matters
Not every cookie is authentication, but session-like cookies deserve stricter defaults. Impact depends on how your app uses each cookie.
How to check
Review Set-Cookie on login and session routes. Confirm Secure on HTTPS-only sites, evaluate HttpOnly for sensitive cookies, validate SameSite behavior for CSRF posture.
How to fix
Default to Secure + HttpOptional for sensitive cookies, SameSite=Lax (or Strict) unless cross-site is required (then SameSite=None with Secure only). Narrow Domain/Path; prefer __Host- when host-only fits.
- Identify owners for the affected component (app, edge, DNS, or mail).
- Make a minimal change and validate in staging or a canary route.
- Deploy with monitoring and rollback readiness.
- Re-run ExposureGrid to confirm the external signal improved.
Run a scan to verify this fix on your domain
Use the same public scanner as the homepage — results honor your plan tier.
Scan your domainWhat ExposureGrid checks
ExposureGrid inspects externally observed Set-Cookie headers across sampled routes.
FAQ
- Why does "__Secure- cookie misconfiguration" appear in ExposureGrid?
- Scanners observe externally visible signals. A finding means our rules matched - validate severity and applicability in your environment.
- Could this be a false positive?
- Yes, depending on context and coverage limits. Especially for heuristic, partial, or pattern-based checks, corroborate with manual review.
- What should I do after changing configuration?
- Re-run a scan to confirm the external signal changed, then enable monitoring where your plan supports it.
ExposureGrid continuously monitors these issues and alerts you before they become exploitable.