Stop Leaking Sessions: A Practical Guide to Secure Cookies

Modern browsers still follow a simple rule: if a cookie isn’t marked Secure, it will happily ride along with any HTTP request to the same host. For session identifiers, antiforgery tokens, or anything else sensitive, that’s a disaster waiting to happen. This post walks through a pragmatic process you can run against any web app to confirm that the Secure flag is set everywhere it needs to be—and how to fix things when it isn’t.

Why You Should Care

Network snoops are real: Coffee-shop Wi-Fi, corporate proxies, misconfigured load balancers—if a cookie travels over plain HTTP, it can be stolen.
Mixed-content and downgrade attacks still happen: All it takes is one HTTP asset or redirect chain and your unlocked cookie hitches a ride.
Compliance pressure: PCI-DSS, SOC2, and most pen-test checklists now flag non-secure cookies as high severity issues.

Quick Health Check

Load the site over HTTPS and open your browser’s storage inspector (Chrome DevTools → Application → Cookies).
Sort by the “Secure” column. Anything that says false deserves investigation.
Double-check with curl so you see the raw Set-Cookie headers:curl -k -i -L https://your-app.com/login Scan for cookies missing secure; httponly; samesite=....
Probe multiple flows: Log in, log out, submit forms, and hit APIs—new cookies can appear in surprising places.

Common Culprits

Framework defaults that predate HTTPS-by-default practices.
Custom middleware or legacy modules issuing Set-Cookie without the attribute.
Reverse proxies that terminate TLS but don’t forward X-Forwarded-Proto, leaving the app thinking the request is HTTP.

Fixing the Gaps

Centralize a cookie policy: In ASP.NET Core, app.UseCookiePolicy(new CookiePolicyOptions { Secure = CookieSecurePolicy.Always, … }); ensures every cookie defaults to HTTPS-only.
Harden the high-value cookies: Authentication tickets, antiforgery tokens, session IDs. Explicitly require Secure, HttpOnly, and set SameSite based on your auth flow.
Enforce HTTPS everywhere: Redirect HTTP to HTTPS, add HSTS, and kill any mixed-content requests that might trigger a downgrade.
Educate your team: Bake “Secure + HttpOnly + SameSite” into code reviews and linting rules so new cookies don’t regress.

Verification Checklist

[ ] Browser DevTools shows every cookie with Secure = true.
[ ] curl (or your favorite scanner) confirms all Set-Cookie headers include secure.
[ ] Automated tests or smoke checks cover login, form submissions, and API calls.
[ ] Documentation notes the policy and how to validate it when new features ship.

Lessons Learned

Cookies are easy to overlook; schedule recurring audits, especially after framework updates.
Don’t forget non-auth cookies—TempData, antiforgery, and feature-specific cookies all need the same treatment.
Security docs and runbooks matter. When something breaks (e.g., because SameSite=Strict blocked an OAuth flow), write down the fix so you don’t repeat the same cycle.

Locking down cookies is low-effort, high-impact work. A few minutes with DevTools and curl can prevent hours of cleanup after a session hijack. Make it part of your release routine and move on with confidence.