Technical
Secure cookie
Secure cookie is a cookie carrying the `Secure` attribute, which tells the browser to send it only over HTTPS. On plain HTTP the cookie stays at home.
How it is measured
Look for `Secure` in the `Set-Cookie` header or the tick in DevTools. Then test: load the site over `http://`, if reachable, and read the request's Cookie header. The secure cookie should be absent. `curl -v` to the HTTP URL without following redirects shows what goes out.
Scanners report cookies without Secure on HTTPS sites. Localhost is a special case, since browsers treat it as secure for this purpose.
Worked example
A coffee shop's WordPress site serves HTTPS, but the login cookie lacks Secure. On the cafe's guest Wi-Fi, a visitor's phone follows an old `http://` link and sends the cookie in clear on the first request. A laptop sniffing the network captures it.
Adding Secure and an HSTS header closes the gap. The plain http request no longer carries the cookie, and HSTS upgrades later visits before they leave the browser.
How it differs
A secure cookie restricts the channel to HTTPS. An HttpOnly cookie restricts the reader to the browser, not script. Secure does not hide the value from JavaScript on the page, and HttpOnly does not stop the cookie travelling in clear.
Common errors
Forgetting it on the session cookie. Assuming an HTTPS-only site makes it unnecessary. Setting Secure in a dev environment on HTTP and wondering why login breaks. Overwriting the cookie from a path that omits the attribute. Setting it without redirecting HTTP to HTTPS. Skipping HSTS.
In practice
Add Secure to every cookie on an HTTPS site, redirect HTTP to HTTPS, and enable HSTS once you are sure all subdomains support HTTPS. In development, use HTTPS or localhost.