HSTS is the only way to prevent SSL stripping attacks, but it’s not a magic bullet and requires careful implementation.
Let’s see HSTS in action. Imagine a user browsing your site, example.com.
First, their browser needs to know that example.com always uses HTTPS. This is where the Strict-Transport-Security header comes in. When the browser successfully connects to example.com over HTTPS, the server sends back:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
This header tells the browser:
max-age=31536000: For the next year (31,536,000 seconds), always connect toexample.comusing HTTPS. If the user tries to go tohttp://example.com, the browser will automatically upgrade it tohttps://example.combefore sending the request.includeSubDomains: This rule also applies to all subdomains ofexample.com(e.g.,api.example.com,blog.example.com).preload: This is an opt-in for inclusion in browser-maintained HSTS preload lists. If you include this, and your site is accepted into the list, browsers will ship with this HSTS policy baked in, meaning the first visit to your site will already be HTTPS, even before the server sends the header.
Now, what about cookies? If you’re setting cookies that contain sensitive information (like session IDs), you must ensure they are only sent over HTTPS. This is where the Secure flag on cookies comes into play. When setting a cookie, your server should include:
Set-Cookie: sessionid=abcdef12345; Secure; HttpOnly; Path=/
Secure: This flag tells the browser to only send this cookie over an encrypted HTTPS connection. If the connection were somehow downgraded to HTTP, the browser would not send this cookie.HttpOnly: This flag prevents JavaScript from accessing the cookie, mitigating certain cross-site scripting (XSS) attacks that could steal session cookies.
The combination of HSTS and Secure cookies creates a robust defense. An attacker trying to perform an SSL stripping attack might intercept the initial HTTP request, but HSTS forces the browser to upgrade to HTTPS immediately, rendering the attacker’s attempt to force an HTTP connection useless. Even if the attacker could somehow bypass HSTS (e.g., on the very first visit before the header is received, or if includeSubDomains isn’t set and they target a subdomain), the Secure flag on cookies prevents sensitive data from being sent over the unencrypted HTTP connection.
The preload directive is a powerful tool for ensuring the first visit is secure. Without it, an attacker could potentially perform an SSL stripping attack on a user’s very first visit to your site, before the HSTS header has been received and cached by the browser. By submitting your site to the HSTS preload list, you ensure that major browsers will have your HSTS policy embedded, guaranteeing HTTPS from the absolute first connection. This requires a commitment to HTTPS for your entire domain and all subdomains, as the preload submission process is strict.
The real power of HSTS, especially with preload, is that it shifts the security burden from the user and the application logic to the browser itself. The browser enforces the HTTPS connection, making it incredibly difficult for an attacker to downgrade the connection or intercept sensitive cookies, even if they are on the same network. It’s a declarative security policy that the browser diligently follows.
The most surprising thing about HSTS is how it interacts with DNS prefetching and other browser optimizations. While HSTS is primarily about enforcing HTTPS, its preload directive means browsers will often establish an initial TLS connection to your domain before the user even clicks a link or types your URL. This is because the browser checks its preloaded list and, if found, might proactively set up a connection to ensure a faster, secure experience. This has implications for certificate management and server performance, as your server might see connections from browsers that haven’t even "requested" your page yet, but are just ensuring they can connect securely.
Once HSTS is in place and the Secure flag is used for all sensitive cookies, the next step in hardening your site’s security is to implement Content Security Policy (CSP) to mitigate XSS vulnerabilities that could otherwise lead to session hijacking even with secure cookies.