Skip to main content
← All controls
SC-8 / SC-13 / A.14.1.2 / A.14.1.3 NIST SP 800-52 Rev 2

HSTS enabled on public sites

Demonstrate that all public-facing web applications and sites enforce HTTPS-only communication through properly configured HTTP Strict Transport Security headers with adequate expiry periods.

Description

What this control does

HTTP Strict Transport Security (HSTS) is a security header that instructs browsers to communicate with the web server exclusively over HTTPS, preventing protocol downgrade attacks and cookie hijacking. When enabled, the server sends a Strict-Transport-Security header containing directives such as max-age, includeSubDomains, and preload, which the browser enforces for the specified duration. This control is critical for public-facing websites to ensure encrypted communication cannot be bypassed through man-in-the-middle attacks or user error.

Control objective

What auditing this proves

Demonstrate that all public-facing web applications and sites enforce HTTPS-only communication through properly configured HTTP Strict Transport Security headers with adequate expiry periods.

Associated risks

Risks this control addresses

  • Man-in-the-middle attackers intercept initial HTTP requests before redirection to HTTPS, capturing sensitive session tokens or credentials
  • Users accessing sites via HTTP links or typing URLs without protocol specification expose data in cleartext transmission
  • SSL-stripping attacks downgrade HTTPS connections to HTTP, bypassing encryption without user awareness
  • Cookie theft occurs when secure cookies are transmitted over unencrypted HTTP connections initiated by attackers
  • Network-level adversaries forge responses to HTTP requests, injecting malicious content before HTTPS upgrade occurs
  • Mixed content vulnerabilities allow attackers to exploit HTTP resources loaded within HTTPS pages to compromise the secure context
  • Browser trust decisions are subverted when users habitually click through certificate warnings on HTTP connections

Testing procedure

How an auditor verifies this control

  1. Obtain an inventory of all public-facing domains, subdomains, and web applications accessible from the internet.
  2. Use browser developer tools or command-line utilities (curl, wget) to send HTTPS requests to each identified domain and capture response headers.
  3. Verify the presence of the Strict-Transport-Security header in HTTPS responses from production web servers.
  4. Examine the max-age directive value to confirm it meets organizational policy minimum (typically 31536000 seconds for one year).
  5. Check whether the includeSubDomains directive is present if the organization uses subdomains under the parent domain.
  6. Test that the HSTS policy is applied by accessing the site via HTTP and verifying the browser automatically upgrades to HTTPS on subsequent requests.
  7. Review web server configuration files (Apache, Nginx, IIS, load balancers) to confirm HSTS headers are configured at the infrastructure level, not solely application layer.
  8. Validate that HSTS preload list submission status if the organization claims preload compliance, by checking hstspreload.org or Chromium source.
Evidence required Collect HTTP response header captures showing Strict-Transport-Security values for each public domain, screenshots of browser developer tools network tabs displaying header details, and configuration file excerpts from web servers or load balancers demonstrating HSTS policy enforcement. Retain curl or wget command outputs with verbose flags showing full header exchanges, and if applicable, screenshots from hstspreload.org confirming preload status.
Pass criteria All public-facing domains return a valid Strict-Transport-Security header over HTTPS with a max-age value of at least 31536000 seconds, includeSubDomains directive where subdomains exist, and no domains accessible via unencrypted HTTP without automatic HTTPS upgrade.

Where this control is tested

Audit programs including this control