Cookie Security Checker Guide
Use this guide to understand what the Cookie Security Checker is validating, which cookie flags matter most for real session security, and how to tighten them without breaking authentication, payment, or embedded flows.
Overview
Cookie hardening is about limiting how session state can be stolen, replayed, or misused. The checker is looking for missing Secure, HttpOnly, and SameSite protections, but the real goal is a policy that matches the application flow without leaving unsafe defaults behind.
Flags to prioritize first
- Secure: Authentication cookies should not travel over plaintext HTTP.
- HttpOnly: This reduces direct access from client-side script if XSS is present.
- SameSite: The correct setting depends on the real login, payment, and embed flow.
Cookie Flags and Common Mistakes
| Flag | Recommended default | Common pitfall |
|---|---|---|
| Secure | Enable on any cookie that matters on HTTPS sites | Leaving auth cookies usable on plaintext HTTP. |
| HttpOnly | Enable on session and auth cookies | Letting sensitive cookies stay readable from JavaScript. |
| SameSite=Lax | Good default for many auth flows | Assuming it behaves like Strict in every cross-site journey. |
| SameSite=None; Secure | Use only when cross-site behavior is genuinely required | Applying None without Secure or without understanding the flow. |
Practical Cookie Examples
res.cookie('session', sessionToken, {
httpOnly: true,
secure: true,
sameSite: 'lax',
path: '/',
maxAge: 1000 * 60 * 60 * 8
});Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=NoneRecommended Remediation Flow
- Inventory cookie purpose first Separate auth, CSRF, preferences, analytics, and third-party cookies before applying blanket rules.
- Lock down session cookies first Apply Secure and HttpOnly to auth cookies before polishing lower-risk cookies.
- Choose SameSite based on the real flow Document whether login, payment, or embedded experiences require Lax, Strict, or None.
- Retest sign-in and sign-out end to end Cookie fixes often look correct in headers but still break user journeys after deployment.
Troubleshooting Common Issues
Sign-in works locally but breaks in production
This is often a Secure or domain-scope problem, especially when local development uses HTTP and production uses HTTPS.
- Check whether the cookie is being dropped because Secure is enabled on a non-HTTPS environment.
- Confirm the domain attribute matches the real host.
- Review reverse proxy behavior if the app thinks it is serving HTTP behind TLS termination.
Cross-site login or embedded flows break after SameSite changes
The application probably depends on a real cross-site transition and SameSite=Lax or Strict is now blocking it.
- Validate whether the flow uses redirects from another domain, an iframe, or a third-party identity provider.
- Use SameSite=None; Secure only for the cookies that truly require cross-site behavior.
- Retest browser-specific behavior because older clients handle SameSite=None differently.
Validation Checklist
Post-fix validation
- Confirm the final Set-Cookie attributes on the public response, not only the app config.
- Retest login, logout, password reset, payment, and embedded flows affected by SameSite.
- Verify session cookies are Secure and HttpOnly where those protections should exist.
- Run the Cookie Security Checker again and compare the remaining findings against the intended cookie inventory.
FAQ
Should every cookie be HttpOnly?
Sensitive cookies should be. Some low-risk client-state cookies may still need frontend access.
- Keep auth and refresh cookies HttpOnly whenever possible.
- Split cookies by purpose instead of weakening sensitive cookies.
- Document why a readable cookie is safe before leaving it accessible to script.
Is SameSite=Strict always the best choice?
No. It is the strongest choice, but not always the most compatible one.
- Use Strict when the journey does not rely on cross-site entry points.
- Use Lax for many normal login patterns.
- Use None only when the business flow genuinely requires cross-site cookie behavior.