Why the BBC's cautious HSTS rollout matters
HTTPS is now the baseline for the modern web. According to the HTTP Archive's 2021 Web Almanac, roughly 91% of all desktop and mobile requests are served over HTTPS. That adoption isn't just about encryption—it's a gate for critical features like Service Worker, HTTP/2, and HTTP/3.
But serving HTTPS isn't the same as enforcing it. Neil Craig, a lead technical architect at the BBC, recently noted on Twitter that the organization is slowly rolling out HTTP Strict Transport Security (HSTS) for bbc.com. The approach highlights a safer way to handle the transition for large, complex sites.
The problem with redirect-based security
Most web servers listen on both port 80 (HTTP) and port 443 (HTTPS). When a user types a bare domain into the address bar—without the https:// prefix—some browsers still default to the insecure HTTP version, a legacy behavior. The common fix is an HTTP-to-HTTPS redirect, which works but has issues:
- The server receives an HTTP request.
- The server issues a redirect to the HTTPS resource.
- The server negotiates a secure connection.
- The content loads normally.
Redirects are not foolproof. They can be misconfigured, leaving an insecure version of the site reachable. Even with correct configuration, the initial request travels over plain HTTP, exposing users to man-in-the-middle attacks during the redirect phase.
How HSTS removes the weak link
HSTS is controlled by the Strict-Transport-Security HTTP response header on HTTPS requests. Once a browser sees it, subsequent visits trigger a "307 Internal Redirect"—the browser handles the redirect itself, not the server. Since the request never leaves the browser, it cannot be intercepted, eliminating that exposure window. As a side benefit, this internal redirect is very fast, removing noticeable latency from the HTTP-to-HTTPS hop.
The header syntax mirrors Cache-Control's max-age directive, specifying how long the policy is active, in seconds.
A max-age value of 3600, for instance, applies the policy for only one hour.
Deploying HSTS safely: start tiny, grow gradually
The major risk with HSTS is deploying it before your origin is truly secure. If any subdomain still serves resources over HTTP, an HSTS header can break your site.
The BBC's rollout is a model of caution. The initial header value for bbc.com was max-age=10—a policy effective for only ten seconds. That provides little direct benefit, but it's a safe way to test whether HSTS causes any problems. The BBC has since incrementally increased the value to max-age=86400 (24 hours), and it's likely to keep climbing.
The lesson: don't launch with a long max-age. You could end up debugging while users hit broken pages. Start small, observe, and then scale up. Once you're confident, the recommended values are one to two years.
The HSTS preload list for first-visit protection
An HSTS policy only kicks in after the first visit to a site, meaning the initial connection remains vulnerable to the redirect issue. Submitting your domain to the HSTS preload list changes that. This list is hardcoded into browsers, so they know your site is strictly HTTPS before the first visit. With preload, even the initial navigation is protected and the HTTP-to-HTTPS hop is instantaneous.
If a publisher of the BBC's scale is comfortable testing HSTS incrementally, it's a signal that most sites can adopt it. The key is patience: roll out slowly, watch for breakage, and reserve the preload list for when you're certain nothing is broken. The payoff is a safer and faster experience for users on every visit.
