EngineeringScore
Security Small

Mark cookies as Secure

The Secure attribute on a cookie tells the browser to only ever transmit it over an HTTPS connection. Without it, the same cookie a user's browser sends on a secure page could also be sent in plaintext if the user (or an attacker) ever triggers a request to the HTTP version of the site.

Why it matters

Cookies without the Secure attribute can still be sent over an unencrypted connection if the browser is ever made to request the site over plain HTTP, exposing whatever value the cookie holds to anyone on the same network.

How to fix

  1. 1 Add the Secure attribute to every first-party cookie the app sets.
  2. 2 Confirm the site is fully served over HTTPS first.

Common mistakes

  • Marking new cookies Secure but forgetting legacy cookies set by older code paths or third-party libraries.
  • Adding Secure without first confirming the entire site is served over HTTPS, which can silently break login if some page still loads over HTTP.
  • Assuming Secure alone is sufficient: it protects the transport but not client-side script access, which requires HttpOnly as well.

How to verify

  1. 1 Open devtools, inspect the cookies for the site, and confirm every first-party session/auth cookie has the Secure flag set.
  2. 2 Attempt to load the site over plain HTTP and confirm the cookie is not sent with the request.
  3. 3 A cookie can be first-party by domain and still not be this site's own code to fix: if it was written by an analytics/ads snippet (name matches a known vendor pattern), see the vendor-managed Secure cookies article instead; if it belongs to another domain entirely, see the third-party cookies finding.

Related checks

Security HTTPSSecurity Cookies HttponlySecurity Cookies Secure Vendor Managed

Ready to see where you stand?

Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.

Scan your site