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. 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. Rising MITM Attacks 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. Zero Trust Architecture 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. 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. API Security 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. Remote Workforce 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. Supply Chain 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 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. Browser HSTS Cache 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. HSTS Policy Engine 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. TLS/SSL Handshake Layer 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. Server Response Handler 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 1 (Prevention) 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 2 (Enforcement) 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 3 (Persistence) 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. Layer 4 (Coverage) 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. Man-in-the-Middle (MITM) Attacks SSL Stripping: Sophisticated attackers could intercept HTTPS redirects and keep the connection on HTTP, allowing them to read all transmitted data in plaintext. SSL Stripping Mixed Content Issues: Users might inadvertently access insecure versions of sites through old bookmarks, manually typed URLs without "https://", or compromised links. Mixed Content Issues 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: Initial Contact: User visits a website over HTTPS for the first time Policy Delivery: Server sends HSTS header with the response Policy Storage: Browser stores the HSTS policy for the specified duration Automatic Upgrade: All future requests to that domain are automatically upgraded to HTTPS Certificate Validation: Browser strictly enforces valid SSL/TLS certificates with no bypass option Initial Contact: User visits a website over HTTPS for the first time Initial Contact Policy Delivery: Server sends HSTS header with the response Policy Delivery Policy Storage: Browser stores the HSTS policy for the specified duration Policy Storage Automatic Upgrade: All future requests to that domain are automatically upgraded to HTTPS Automatic Upgrade Certificate Validation: Browser strictly enforces valid SSL/TLS certificates with no bypass option Certificate Validation 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. max-age 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. includeSubDomains preload: Signals that the site owner wants their domain included in browsers' HSTS preload lists, protecting even the very first visit. preload 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 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. Important 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. security mechanism 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. performance-focused protocol 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. QUIC protocol 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 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 Feature HSTS HTTP/2 HTTP/3 Feature Feature HSTS HSTS HTTP/2 HTTP/2 HTTP/3 HTTP/3 Purpose Security enforcement Performance Performance Purpose Purpose Security enforcement Security enforcement Performance Performance Performance Performance Layer Policy / Browser Application Protocol Application Protocol Layer Layer Policy / Browser Policy / Browser Application Protocol Application Protocol Application Protocol Application Protocol Transport Any HTTP version TCP + TLS UDP + QUIC Transport Transport Any HTTP version Any HTTP version TCP + TLS TCP + TLS UDP + QUIC UDP + QUIC Main Benefit Prevents downgrade attacks Faster page loads Reduced latency Main Benefit Main Benefit Prevents downgrade attacks Prevents downgrade attacks Faster page loads Faster page loads Reduced latency Reduced latency Encryption Enforces it Optional (Usually with TLS) Required Encryption Encryption Enforces it Enforces it Optional (Usually with TLS) Optional (Usually with TLS) Required 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 curl -I https://example.com # Look for this in the response: # Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Response: 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 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 curl -I https://howtogeek.com # Look for this in the response: # Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Response: 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 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 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') 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: 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 /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. Chrome/Edge chrome://net-internals/#hsts Firefox: The HSTS cache is stored in SiteSecurityServiceState.txt in your Firefox profile directory. Firefox SiteSecurityServiceState.txt When checking the browser HSTS cache, verify the following: Domain Presence: Confirm your domain appears in the HSTS cache after visiting it over HTTPS Expiration Time: Check the expiry timestamp to ensure max-age is set correctly (should be far in the future for production sites) SubDomain Flag: Verify sts_include_subdomains is set to true if you're using includeSubDomains directive Mode: Ensure the mode shows as force-https or similar, indicating HTTPS enforcement is active Upgrade Behavior: Test by typing http://yourdomain.com in the address bar - it should automatically change to https:// before any network request Preload Status: If submitted to preload list, verify sts_preload flag is present Domain Presence: Confirm your domain appears in the HSTS cache after visiting it over HTTPS Domain Presence Expiration Time: Check the expiry timestamp to ensure max-age is set correctly (should be far in the future for production sites) Expiration Time expiry SubDomain Flag: Verify sts_include_subdomains is set to true if you're using includeSubDomains directive SubDomain Flag sts_include_subdomains true Mode: Ensure the mode shows as force-https or similar, indicating HTTPS enforcement is active Mode force-https Upgrade Behavior: Test by typing http://yourdomain.com in the address bar - it should automatically change to https:// before any network request Upgrade Behavior http://yourdomain.com https:// Preload Status: If submitted to preload list, verify sts_preload flag is present Preload Status sts_preload Chrome HSTS Query Example: Chrome HSTS Query Example: Enter your domain in the "Query HSTS/PKP domain" field Click "Query" - if configured, you'll see: "Found", dynamic_sts_domain, sts_include_subdomains (if applicable), and expiry date To delete (for testing): Enter domain in "Delete domain security policies" and click "Delete" Enter your domain in the "Query HSTS/PKP domain" field Click "Query" - if configured, you'll see: "Found", dynamic_sts_domain, sts_include_subdomains (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 securityheaders.com - Comprehensive security header analysis securityheaders.com hstspreload.org - Check HSTS preload eligibility hstspreload.org ssllabs.com/ssltest - Complete SSL/TLS and HSTS testing ssllabs.com/ssltest Implementation Best Practices Start Conservative: Begin with a short max-age (e.g., 300 seconds) to test your implementation Gradually Increase: Once confident, increase to longer periods (1-2 years) Test Subdomains: Ensure all subdomains support HTTPS before using includeSubDomains Monitor Certificate Expiry: Set up alerts well before SSL certificates expire Consider Preloading: For maximum security, submit to the HSTS preload list after thorough testing Implement Monitoring: Use security headers checkers and monitoring tools to verify HSTS is properly configured Plan Certificate Renewal: Ensure automated certificate renewal processes are in place and tested Regular Testing: Schedule periodic HSTS configuration checks using automated scripts Start Conservative: Begin with a short max-age (e.g., 300 seconds) to test your implementation Start Conservative Gradually Increase: Once confident, increase to longer periods (1-2 years) Gradually Increase Test Subdomains: Ensure all subdomains support HTTPS before using includeSubDomains Test Subdomains Monitor Certificate Expiry: Set up alerts well before SSL certificates expire Monitor Certificate Expiry Consider Preloading: For maximum security, submit to the HSTS preload list after thorough testing Consider Preloading Implement Monitoring: Use security headers checkers and monitoring tools to verify HSTS is properly configured Implement Monitoring Plan Certificate Renewal: Ensure automated certificate renewal processes are in place and tested Plan Certificate Renewal Regular Testing: Schedule periodic HSTS configuration checks using automated scripts Regular Testing 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.
