While working with a colleague on web security, I heard that their team is enabling HSTS as part of their Black Friday security upgrades to their website. The first question that popped up into my mind is why do you require HSTS if there is HTTP/2 and HTTP/3. So, let’s learn about HSTS and why it is required in modern web security. This article is inline and also an extension to my previous publication on SSL certificate management.

For starters, HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps protect websites against protocol downgrade attacks and cookie hijacking. Introduced in 2012 as RFC 6797, HSTS has become a critical component of modern web security infrastructure, ensuring that browsers communicate with web servers exclusively over secure HTTPS connections.

HSTS in Today's Cybersecurity Landscape

In the current threat environment, HSTS has evolved from a recommended practice to an essential security control. Modern cybersecurity challenges make HSTS more relevant than ever:

Rising MITM Attacks: With the proliferation of public Wi-Fi networks, coffee shops, airports, and coworking spaces, man-in-the-middle attacks have become increasingly common. Attackers can easily set up rogue access points to intercept unencrypted traffic.

Zero Trust Architecture: HSTS aligns perfectly with Zero Trust principles by eliminating implicit trust in network connections. It enforces encryption at the browser level, assuming that all networks are potentially hostile.

Compliance Requirements: Regulations like PCI DSS, GDPR, and HIPAA increasingly mandate encrypted communications. HSTS provides verifiable enforcement of encryption policies, helping organizations meet compliance requirements.

API Security: With the explosion of API-driven architectures and microservices, HSTS protects API endpoints from downgrade attacks, ensuring that service-to-service communications remain encrypted.

Remote Workforce: The shift to remote and hybrid work models has expanded the attack surface. HSTS provides consistent security regardless of where users connect from, protecting corporate applications accessed from home networks or public spaces.

Supply Chain Attacks: HSTS helps mitigate risks from compromised network infrastructure by ensuring that even if intermediate network devices are compromised, they cannot force downgrade attacks.

What is HSTS?

HSTS is a security header that instructs web browsers to only interact with a website using HTTPS, never HTTP. Once a browser receives this header from a website, it automatically converts all future HTTP requests to HTTPS before making the connection. This happens entirely on the client side, preventing insecure connections from ever being attempted.

The HSTS header looks like this:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 

HSTS Architecture

Understanding HSTS architecture is crucial for proper implementation. The architecture consists of several interconnected components working together to enforce secure communications.

Architectural Components

Browser HSTS Cache: Each browser maintains a local database of HSTS policies. This cache stores domain names, policy expiration times, and whether subdomains are included. The cache is persistent across browser sessions and survives restarts.

HSTS Policy Engine: When a user attempts to navigate to a URL, the browser's policy engine checks the HSTS cache before making any network request. If a valid HSTS policy exists, the engine automatically upgrades HTTP to HTTPS.

TLS/SSL Handshake Layer: HSTS enforces strict certificate validation. If the TLS handshake fails or the certificate is invalid, the browser blocks the connection entirely with no option for users to bypass the warning.

Server Response Handler: The web server must include the HSTS header in HTTPS responses. This header is ignored if sent over HTTP, preventing attackers from injecting false HSTS policies.

Multi-Layer Security Architecture

HSTS implements defense-in-depth through four distinct security layers, each building upon the previous to create a comprehensive security posture. This layered approach ensures that even if one mechanism is bypassed, others remain in place to protect the connection.

\ Layer 1 (Prevention) stops attacks before they occur by automatically upgrading all HTTP requests to HTTPS at the browser level, eliminating the attack surface for protocol downgrade attempts.

Layer 2 (Enforcement) ensures certificate integrity through strict validation without allowing users to bypass security warnings, preventing certificate-based attacks even from sophisticated adversaries.

Layer 3 (Persistence) maintains protection across sessions through long-term browser caching and preload lists, ensuring continuous security even after browser restarts or across different devices.

Layer 4 (Coverage) extends protection to the entire domain hierarchy via includeSubDomains, preventing attackers from exploiting forgotten or misconfigured subdomains as entry points into the organization's infrastructure.

\n \n Why HSTS is Required

The Problem: Protocol Downgrade Attacks

Before HSTS, even if a website supported HTTPS, users could still access it via HTTP. This created several vulnerabilities:

Man-in-the-Middle (MITM) Attacks: Attackers on the network path could intercept initial HTTP requests before they were redirected to HTTPS, stealing sensitive information or injecting malicious content.

SSL Stripping: Sophisticated attackers could intercept HTTPS redirects and keep the connection on HTTP, allowing them to read all transmitted data in plaintext.

Mixed Content Issues: Users might inadvertently access insecure versions of sites through old bookmarks, manually typed URLs without "https://", or compromised links.

How HSTS Solves These Problems

HSTS eliminates the window of vulnerability by ensuring that after the first HTTPS visit, the browser refuses to make any insecure connection to that domain. Even if an attacker tries to redirect a user to HTTP, the browser automatically upgrades the request to HTTPS, thwarting the attack.

How HSTS Works

The HSTS workflow follows these steps:

1. Initial Contact: User visits a website over HTTPS for the first time
2. Policy Delivery: Server sends HSTS header with the response
3. Policy Storage: Browser stores the HSTS policy for the specified duration
4. Automatic Upgrade: All future requests to that domain are automatically upgraded to HTTPS
5. Certificate Validation: Browser strictly enforces valid SSL/TLS certificates with no bypass option

HSTS Header Parameters

The HSTS header includes several important directives:

max-age: Specifies how long (in seconds) the browser should remember to only access the site via HTTPS. Common values range from one year (31536000 seconds) to two years.

includeSubDomains: When present, this directive applies the HSTS policy to all subdomains of the host's domain name, creating comprehensive protection across the entire domain hierarchy.

preload: Signals that the site owner wants their domain included in browsers' HSTS preload lists, protecting even the very first visit.

When to Use HSTS

HSTS should be implemented when:

• Your website handles sensitive user data (login credentials, personal information, payment details)
• You've fully migrated to HTTPS across all pages and resources
• All subdomains support HTTPS (if using includeSubDomains)
• You want to prevent SSL stripping attacks
• You're committed to maintaining valid SSL/TLS certificates
• You need to meet compliance requirements (PCI DSS, HIPAA, GDPR)
• Your application serves API endpoints that require secure communications

Important: Don't enable HSTS if you still need HTTP access to any part of your site or if SSL certificate renewal might fail, as users won't be able to access your site during certificate issues.

HSTS vs HTTP/2 vs HTTP/3

It's important to understand that HSTS, HTTP/2, and HTTP/3 serve different purposes and are not alternatives to each other.

HSTS: Security Policy

HSTS is a security mechanism, not a protocol. It doesn't change how data is transmitted but enforces that transmission happens securely. HSTS works with HTTP/1.1, HTTP/2, and HTTP/3.

HTTP/2: Performance Protocol

HTTP/2 is a performance-focused protocol that improves on HTTP/1.1 with multiplexing, header compression, and server push capabilities. HTTP/2 doesn't inherently provide security but typically works over TLS. HSTS can enforce that HTTP/2 connections use HTTPS.

HTTP/3: Performance with QUIC

HTTP/3 is the latest version, built on QUIC protocol with faster connection establishment and improved multiplexing. HTTP/3 requires encryption by design but still benefits from HSTS policy enforcement at the browser level.

Comparison Table

| Feature | HSTS | HTTP/2 | HTTP/3 | |----|----|----|----| | Purpose | Security enforcement | Performance | Performance | | Layer | Policy / Browser | Application Protocol | Application Protocol | | Transport | Any HTTP version | TCP + TLS | UDP + QUIC | | Main Benefit | Prevents downgrade attacks | Faster page loads | Reduced latency | | Encryption | Enforces it | Optional (Usually with TLS) | Required |

Testing HSTS Implementation

Proper testing is crucial to ensure HSTS is configured correctly. Here are practical methods to test your HSTS setup:

Using cURL

Open a terminal or a command prompt on your machine and run the below command to test if your server sends the HSTS header:

curl -I https://example.com # Look for this in the response: # Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 

Response:

HTTP/2 200  content-type: text/html etag: "84238dfc8092e5d9c0dac8ef93371a07:1736799080.121134" last-modified: Mon, 13 Jan 2025 20:11:20 GMT cache-control: max-age=86000 date: Sun, 05 Oct 2025 16:53:35 GMT alt-svc: h3=":443"; ma=93600 

The entry you are looking for is not seen in the response as the website is not HSTS configured. Let's see a website with HSTS configured

curl -I https://howtogeek.com # Look for this in the response: # Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 

Response:

HTTP/2 301 server: nginx date: Sun, 05 Oct 2025 16:53:45 GMT content-type: text/html content-length: 162 location: https://www.howtogeek.com/ alt-svc: h3=":443"; ma=86400 x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block x-content-type-options: nosniff referrer-policy: no-referrer-when-downgrade content-security-policy: default-src * data: 'unsafe-eval' 'unsafe-inline' blob: strict-transport-security: max-age=31536000; includeSubDomains; preload 

You can see the entry in the response 

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload 

Using Python Script

Create a comprehensive HSTS testing script:

import requests from urllib.parse import urlparse def test_hsts(url): """Test HSTS configuration for a given URL""" # Ensure HTTPS if not url.startswith('https://'): url = 'https://' + url.replace('http://', '') try: # Make HTTPS request response = requests.get(url, timeout=10) hsts_header = response.headers.get('Strict-Transport-Security') if hsts_header: print(f"✓ HSTS Header Found: {hsts_header}") # Parse header components if 'max-age' in hsts_header: max_age = hsts_header.split('max-age=')[1].split(';')[0] days = int(max_age) / 86400 print(f" Max-Age: {max_age} seconds ({days:.0f} days)") if 'includeSubDomains' in hsts_header: print(" ✓ includeSubDomains enabled") if 'preload' in hsts_header: print(" ✓ Preload directive present") else: print("✗ No HSTS Header found") except Exception as e: print(f"Error testing {url}: {e}") # Test your domain test_hsts('example.com') test_hsts('howtogeek.com') 

Response:

/Users/vmac/Documents/Code/Python/.venv/bin/python /Users/vmac/Documents/Code/Python/hsts.py ✗ No HSTS Header found ✓ HSTS Header Found: max-age=31536000; includeSubDomains; preload Max-Age: 31536000 seconds (365 days) ✓ includeSubDomains enabled ✓ Preload directive present Process finished with exit code 0 

Checking Browser HSTS Cache

Chrome/Edge: Navigate to chrome://net-internals/#hsts and query your domain to see stored HSTS policies.

Firefox: The HSTS cache is stored in SiteSecurityServiceState.txt in your Firefox profile directory.

When checking the browser HSTS cache, verify the following:

1. Domain Presence: Confirm your domain appears in the HSTS cache after visiting it over HTTPS
2. Expiration Time: Check the expiry timestamp to ensure max-age is set correctly (should be far in the future for production sites)
3. SubDomain Flag: Verify sts_include_subdomains is set to true if you're using includeSubDomains directive
4. Mode: Ensure the mode shows as force-https or similar, indicating HTTPS enforcement is active
5. Upgrade Behavior: Test by typing http://yourdomain.com in the address bar - it should automatically change to https:// before any network request
6. Preload Status: If submitted to preload list, verify sts_preload flag is present

Chrome HSTS Query Example:

• Enter your domain in the "Query HSTS/PKP domain" field
• Click "Query" - if configured, you'll see: "Found", dynamicstsdomain, stsincludesubdomains (if applicable), and expiry date
• To delete (for testing): Enter domain in "Delete domain security policies" and click "Delete"

Online Testing Tools

Use these online services for quick validation:

• securityheaders.com - Comprehensive security header analysis
• hstspreload.org - Check HSTS preload eligibility
• ssllabs.com/ssltest - Complete SSL/TLS and HSTS testing

Implementation Best Practices

1. Start Conservative: Begin with a short max-age (e.g., 300 seconds) to test your implementation
2. Gradually Increase: Once confident, increase to longer periods (1-2 years)
3. Test Subdomains: Ensure all subdomains support HTTPS before using includeSubDomains
4. Monitor Certificate Expiry: Set up alerts well before SSL certificates expire
5. Consider Preloading: For maximum security, submit to the HSTS preload list after thorough testing
6. Implement Monitoring: Use security headers checkers and monitoring tools to verify HSTS is properly configured
7. Plan Certificate Renewal: Ensure automated certificate renewal processes are in place and tested
8. Regular Testing: Schedule periodic HSTS configuration checks using automated scripts

Conclusion

HSTS is an essential security mechanism for modern websites, providing robust protection against protocol downgrade attacks in today's complex threat landscape. As organizations adopt Zero Trust architectures and face increasingly sophisticated attacks, HSTS forms a critical first line of defense by enforcing encrypted connections at the browser level. Unlike HTTP/2 and HTTP/3, which focus on performance improvements, HSTS is purely a security policy that works alongside these protocols to create a comprehensive security and performance strategy. When implemented correctly with proper architectural understanding, HSTS becomes an indispensable component of defense-in-depth security posture.

\