HSTS and PCI DSS: What HTTP Strict Transport Security Does for a Payment Site

HTTP Strict Transport Security (HSTS) is a response header that tells a browser to use only HTTPS for a site from then on. PCI DSS v4.0.1 does not name it. It matters to a site that takes payments because it closes a gap HTTPS alone leaves open, and because it is one of the headers a payment page's change detection is likely to watch. This article covers what it does, how it relates to the standard, and how to deploy it safely. The mechanism is defined in RFC 6797.

The gap HTTPS leaves

HTTPS is HTTP carried inside TLS. Most sites also answer on plain HTTP and redirect to HTTPS. That first request goes out unencrypted: when someone types the address without https://, or follows an old http:// link, an attacker on the network path (a hostile Wi-Fi hotspot, for example) can answer it before the redirect happens and keep the browser on an unencrypted copy of the site. This is usually called SSL stripping. Everything the customer then types, card details included, goes to the attacker.

HSTS removes that first request. Once a browser has seen the header over a valid HTTPS connection, it converts every later http:// request for the site to https:// itself, before anything leaves the machine, for as long as the header's max-age says. It also stops the user clicking through a certificate warning for that site.

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

How it relates to PCI DSS

• 4.2.1 requires strong cryptography and security protocols for PAN sent over open, public networks, with a protocol that does not fall back to insecure versions. HSTS supports that by stopping the browser falling back to plain HTTP. It is not required by name, and it is not a substitute for a correct TLS configuration.
• 11.6.1 requires a change- and tamper-detection mechanism for the security-impacting HTTP headers and scripts of payment pages as the customer's browser receives them. The standard's guidance explains why: comparing headers with known versions can reveal an attempt to disable a control that protects against skimming. HSTS is a common example of such a header, since removing it is a step towards a downgrade.
• 12.3.3 requires an inventory of the cipher suites and protocols in use, reviewed at least once every 12 months. HSTS does not replace that; it only decides whether the browser uses HTTPS, not how strong the HTTPS is.

Deploying it without breaking the site

1. Make everything HTTPS first. Every page, and every image, script, stylesheet and third-party resource the pages load, on every host the header will cover. HSTS turns an HTTP resource into a failure, not a warning.
2. Start with a short max-age. A few minutes while you check nothing breaks, then days, then the value you mean to keep. A long value is hard to take back: browsers that have seen it keep it.
3. Add includeSubDomains only when every subdomain is ready, including internal ones reached by the same browsers. It applies to all of them.
4. Keep certificates renewed. With HSTS in force, an expired certificate makes the site unreachable rather than showing a warning the customer can click past.
5. Record the header. If your payment page is monitored under 11.6.1, the expected Strict-Transport-Security value belongs in its baseline, so a removal or change raises an alert.

The preload list

HSTS still leaves one visit unprotected: the very first, before the browser has seen the header. Browsers ship with a list of domains that are HTTPS-only from the start. The list is managed at hstspreload.org, and to be accepted a site must, among other things, serve a valid certificate, redirect HTTP to HTTPS on the same host, serve every subdomain over HTTPS, and send the header on the base domain with a max-age of at least one year and both includeSubDomains and preload. Getting off the list again is slow, so preload only a domain you are sure will stay HTTPS-only, subdomains included.

What HSTS does not do

It does not encrypt anything itself, strengthen a weak TLS configuration, or say anything about what a page loads once it is open. A payment page with HSTS can still carry a malicious script, which is what 6.4.3 and 11.6.1 are for, and a site whose TLS accepts obsolete versions is still failing 4.2.1 however strict its transport policy.