HSTS (HTTP Strict Transport Security)

Complete Guide to HTTPS Security - Preventing Downgrade Attacks and Forcing Secure Connections

What is HSTS?

HSTS (HTTP Strict Transport Security) is a security header that tells browsers to always use HTTPS when connecting to your domain. Once a browser sees the HSTS header, it remembers this instruction and automatically converts all HTTP requests to HTTPS, even if the user types "http://".

Think of HSTS as a "permanent redirect" that browsers remember. After the first HTTPS visit, browsers automatically use HTTPS for all future connections, preventing attackers from intercepting the first connection or forcing downgrade attacks.

HSTS works by:

1. HTTP Header: Your server sends an HSTS header with HTTPS responses
2. Browser Caching: Browsers cache the HSTS directive for the specified duration
3. Automatic HTTPS: Browsers automatically convert HTTP requests to HTTPS
4. Downgrade Prevention: Browsers reject insecure HTTP connections

How HSTS Works

When a user visits your website:

1. First Visit: User connects via HTTPS (if HTTP redirects are configured)
2. HSTS Header: Your server sends Strict-Transport-Security header
3. Browser Caching: Browser caches the HSTS directive for the max-age duration
4. Future Visits: Browser automatically converts HTTP to HTTPS, even if user types "http://"
5. Downgrade Prevention: Browser rejects insecure HTTP connections during the cache period

This process prevents "first-visit" attacks where attackers intercept the initial connection before HTTPS is established, and prevents downgrade attacks where attackers force unencrypted connections.

HSTS Header Format

The HSTS header is sent as part of HTTPS responses:

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

The header contains directives that specify HSTS behavior:

• max-age=: Duration in seconds that browsers should remember HSTS (31536000 = 1 year, recommended minimum)
• includeSubDomains: Apply HSTS to all subdomains (recommended for government agencies)
• preload: Indicates eligibility for browser preload lists (requires preload submission)

HSTS Directives

HSTS supports several directives:

• max-age: Duration in seconds (required) - how long browsers remember HSTS
• includeSubDomains: Apply to all subdomains (optional but recommended)
• preload: Indicates preload eligibility (optional, requires separate submission)

Why HSTS is Critical for Government Agencies

For government agencies, HSTS is not optional—it's mandatory per CISA requirements. Here's why:

1. Prevents Downgrade Attacks

HSTS prevents attackers from forcing browsers to use unencrypted HTTP connections. Without HSTS, attackers can:

• Intercept the first connection before HTTPS is established
• Force downgrade attacks to HTTP
• Intercept and modify communications
• Steal credentials and sensitive data

2. Protects First Visit

HSTS protects users even on their first visit. While the first connection may still use HTTP (if redirects aren't perfect), HSTS ensures all subsequent connections use HTTPS automatically.

3. Required for CISA Compliance

The Cybersecurity and Infrastructure Security Agency (CISA) mandates HSTS for all government websites. Failure to implement HSTS results in non-compliance, which can lead to:

• Criminal charges for negligence
• Civil liability from data breaches
• Federal grant restrictions
• Insurance claim denials

4. Completes HTTPS Security

HSTS completes HTTPS security. HTTPS provides encryption, but HSTS ensures it's always used. Without HSTS, users may still access your site over HTTP, exposing data to interception.

What Can Go Wrong Without HSTS?

The consequences of operating without HSTS are severe:

Downgrade Attacks

Without HSTS, attackers can force browsers to use unencrypted HTTP connections, even if HTTPS is available. This allows attackers to:

• Intercept communications
• Steal credentials and sensitive data
• Modify web content
• Perform man-in-the-middle attacks

First-Visit Vulnerabilities

Without HSTS, the first connection may use HTTP, allowing attackers to intercept it before HTTPS is established. This is especially dangerous for new users.

User Error

Without HSTS, users who type "http://" or click HTTP links may access your site over unencrypted connections, exposing their data.

How to Implement HSTS

Implementing HSTS requires:

Step 1: Ensure HTTPS is Working

Before implementing HSTS, ensure HTTPS is fully working:

• Valid SSL certificate
• HTTPS accessible on port 443
• HTTP redirects to HTTPS
• All resources load over HTTPS

Step 2: Start with Short max-age

Start with a short max-age (e.g., 300 seconds = 5 minutes) to test HSTS without committing to a long duration. This allows you to verify HSTS is working correctly.

Step 3: Increase max-age Gradually

Gradually increase max-age (to days, then weeks, then months) as you verify HSTS is working correctly. Recommended max-age for production: 31536000 seconds (1 year) or longer.

Step 4: Add includeSubDomains

Add includeSubDomains directive to apply HSTS to all subdomains. This is recommended for government agencies but requires all subdomains to support HTTPS.

Step 5: Consider Preload

Consider submitting your domain to browser HSTS preload lists for maximum protection. Preload ensures browsers use HTTPS even before the first connection, completely eliminating first-visit vulnerabilities.

HSTS Preload

HSTS Preload is a mechanism where browsers include HSTS domains in a built-in list. This ensures browsers use HTTPS even before the first connection, completely eliminating first-visit vulnerabilities.

To be eligible for preload:

• HSTS header must include preload directive
• max-age must be at least 31536000 (1 year)
• includeSubDomains must be present
• Domain must serve valid HSTS header over HTTPS
• Domain must be submitted to hstspreload.org

Warning: Preload is permanent and difficult to reverse. Only use preload if you're committed to HTTPS for all subdomains indefinitely.

Common HSTS Implementation Issues

Several common issues can cause HSTS problems:

1. Missing HSTS Header

If the HSTS header is missing, browsers won't enforce HTTPS, allowing downgrade attacks.

Solution: Ensure HSTS header is sent with all HTTPS responses.

2. Too Short max-age

If max-age is too short, browsers may forget HSTS between visits, allowing downgrade attacks.

Solution: Use max-age of at least 31536000 (1 year) for production.

3. includeSubDomains Without HTTPS Support

If includeSubDomains is used but subdomains don't support HTTPS, those subdomains become inaccessible.

Solution: Ensure all subdomains support HTTPS before using includeSubDomains.

4. Mixed Content

If mixed content (HTTP resources on HTTPS pages) exists, browsers may show security warnings or block content.

Solution: Ensure all resources load over HTTPS.

How YesGov Ensures HSTS is Properly Configured

YesGov handles all aspects of HSTS implementation and management for government agencies:

• Complete Setup: We configure HSTS headers with appropriate max-age and directives
• Proper Configuration: We use max-age of at least 1 year and includeSubDomains when appropriate
• Testing and Validation: We test HSTS configuration to ensure it works correctly
• Preload Submission: We can submit domains to HSTS preload lists for maximum protection
• Ongoing Monitoring: We monitor HSTS configuration and ensure it remains active
• Documentation: All HSTS configuration and status is documented for compliance and insurance purposes

How YesGov Ensures Complete HSTS Protection

At YesGov, we don't just check if HSTS is configured—we perform comprehensive validation of your entire HSTS setup:

• Header Configuration: We configure HSTS headers with appropriate max-age values
• HTTPS Redirects: We ensure all HTTP traffic is redirected to HTTPS
• IncludeSubDomains: We configure HSTS to apply to all subdomains
• Preload Eligibility: We verify domains meet HSTS preload requirements
• Testing and Validation: We test HSTS configuration to ensure it works correctly
• Ongoing Monitoring: We continuously monitor HSTS headers and enforcement
• Documentation: All HSTS configuration and status is documented for compliance

When you host with YesGov, HSTS is properly configured, continuously monitored, and automatically maintained. We handle header configuration, redirects, and preload submission so you don't have to worry about downgrade attacks. This is one of our comprehensive security checks that ensures your agency meets and exceeds federal, state, and industry standards.

Additional Resources

• Back to Learn Home
• SSL/TLS Certificates
• TLS Configuration
• Security Headers
• Check Your Domain's HSTS Status
• Website Security Overview
• Contact YesGov for Services

Learning Guides