Secure Cookies over HTTP: Why It’s Allowed

TL;DR

Yes, a secure cookie can be set from an insecure HTTP connection, but it won’t be transmitted back to the server unless you also connect via HTTPS. The browser allows this as a convenience for upgrading sites and handling redirects. It’s a one-way trip until HTTPS is used.

Why Secure Cookies Can Be Set Over HTTP

1. Browser Flexibility: Browsers allow setting secure cookies even over HTTP to facilitate smooth transitions from insecure (HTTP) to secure (HTTPS) connections. This is useful when a site redirects users from an HTTP page to an HTTPS page.
2. One-Way Operation: When a secure cookie is set via HTTP, the browser stores it but does not send it back to the server with HTTP requests. It only transmits the cookie when communicating over HTTPS.
3. Upgrade Path: This behaviour supports gradual website upgrades to HTTPS without breaking functionality for users who initially connect via HTTP.

How It Works – Step-by-Step

1. Setting the Cookie (HTTP): The server sends a Set-Cookie header over an insecure HTTP connection, including the Secure attribute. For example:

   Set-Cookie: sessionid=abcdefg; Secure

2. Browser Storage: The browser stores the cookie but flags it as secure.
3. Subsequent HTTP Request: If the user makes another request to the same domain over HTTP, the browser will not include the secure cookie in the request header.
4. HTTPS Connection Established: When the user connects via HTTPS (e.g., visiting https://example.com), the browser automatically includes the secure cookie in the request header.

   Cookie: sessionid=abcdefg

Implications for cyber security

• Not a Security Risk (Directly): Setting a secure cookie over HTTP doesn’t directly compromise security because the cookie isn’t sent back over insecure connections. However…
• Mixed Content Warning: Relying on this behaviour can lead to mixed content warnings in browsers if parts of your site are still served over HTTP.
• Redirects and Vulnerabilities: If redirects aren’t handled carefully, a user could be tricked into interacting with the insecure portion of a website after setting a secure cookie. This is why full HTTPS adoption is crucial.

Best Practices

1. Always Use HTTPS: The best practice is to serve your entire website over HTTPS. This eliminates the need for this behaviour and ensures all communication is encrypted.
2. Strict-Transport-Security (HSTS): Implement HSTS to force browsers to always connect via HTTPS, preventing accidental connections over HTTP.

   Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"

3. Cookie Attributes: Always use the Secure attribute for sensitive cookies. Consider also using HttpOnly to prevent client-side JavaScript access and SameSite to mitigate cross-site request forgery (CSRF) attacks.