Browsers may soon enforce HTTPS by default with HSTS-Enforced

The web’s long-standing vulnerability to downgrade attacks may soon be addressed by a new security model called HSTS-Enforced. Currently, browsers default to unencrypted HTTP unless a website explicitly signals support for HTTPS, creating an opening for attackers to intercept or manipulate traffic. HSTS-Enforced proposes reversing this assumption, making encrypted connections the baseline and requiring operators to actively declare when HTTP is necessary for legitimate use cases. This shift could close a decades-old security gap without disrupting the majority of modern web services already using HTTPS by default.

How HSTS-Enforced works

Under the existing HTTP Strict Transport Security (HSTS) standard, websites must opt into encryption by sending a header that instructs browsers to use HTTPS for future visits. HSTS-Enforced builds on this concept but inverts the logic: browsers would assume HTTPS is required unless a trusted signal indicates otherwise. Two mechanisms would enable verifiable exceptions for services that genuinely cannot support encryption. First, DNS-based declarations protected by DNSSEC would allow domain operators to authenticate their need for HTTP at the infrastructure level. Second, a browser-managed preload list would maintain a curated set of services known to require unencrypted connections, similar to existing HSTS preload systems.

When a user attempts to access a site, the browser would first try HTTPS. If the connection fails, it would only fall back to HTTP if either the DNS record or the preload list confirms the destination intentionally operates without encryption. This approach shifts the burden of proof from users and browsers—who currently must detect and enforce security—to website operators, who would need to provide evidence that unencrypted transport is necessary. The change targets the weakest point in current defenses: the initial connection to a domain, where browsers lack prior knowledge of its security preferences.

Compatibility and operational impact

The proposal acknowledges the web’s heterogeneity, where a small but persistent subset of systems—such as legacy industrial controls, diagnostic tools, or internal networks—still rely on HTTP. Forcing HTTPS universally could break these services, so HSTS-Enforced includes safeguards to accommodate legitimate exceptions. However, the model introduces new responsibilities for operators of such systems. They would need to configure DNSSEC-signed records or apply for inclusion in the preload list to signal their requirements, replacing the current passive reliance on browsers’ automatic fallback behavior.

For most website operators, the change would reduce configuration overhead. Instead of manually enabling HSTS or preload lists, secure transport would become the default, aligning with the reality that over 90% of web traffic already uses HTTPS. Performance impact is expected to be minimal, as the change affects connection logic rather than transport efficiency. The primary challenge lies in coordinating the rollout across browsers, DNS providers, and standards bodies to ensure consistent enforcement and exception handling.

What’s next

Implementation of HSTS-Enforced would require a staged approach. The first phase would focus on establishing robust, tamper-resistant mechanisms for signaling HTTP requirements, likely through DNSSEC and preload lists. Only after these systems are stable would browsers begin phasing out automatic fallbacks to HTTP, transitioning from an opt-in to an opt-out security model. The proposal’s authors have released open-source artifacts to support testing and development, but widespread adoption hinges on browser vendors and standards organizations integrating the changes into their roadmaps.

For now, operators can mitigate downgrade risks by enabling HTTPS-Only mode in browsers, keeping software updated, and avoiding certificate warnings. Website owners should implement HSTS with preload lists and DNSSEC where possible to prepare for a future where encryption is the default rather than an optional upgrade.