Enforce HTTPS in Cloudflare by enabling Always Use HTTPS and HSTS for the site. Always Use HTTPS redirects browser traffic to HTTPS, while HSTS tells browsers to stay on HTTPS for future visits. Verify that the origin also serves valid TLS and test redirects carefully, because broken certificates or mixed-content dependencies can cause access failures after HSTS is enabled.
What Always Use HTTPS does versus what HSTS enforces
Always Use HTTPS and HSTS solve related but different problems. Always Use HTTPS is the redirect layer: it sends browser requests to the secure URL when users arrive over plain HTTP. HSTS is the browser policy layer: once a browser learns the rule, it will try HTTPS first for later visits and resist downgrade attempts.
The practical difference matters because redirects are reactive, while HSTS is preventive. A redirect can still allow the first request to begin over HTTP, which leaves room for interception or a failed transition if the origin or certificate is not ready. HSTS changes browser behaviour after the first successful secure visit, so it raises the bar for future connections.
When you use both together, the goal is to make HTTPS the default path in the browser, not just an alternate route. Cloudflare’s Security Headers Guide covers the broader header rollout pattern, including HSTS and preload considerations, so the policy is introduced in a controlled way rather than as an isolated toggle.
What must already work before you enable HSTS
HSTS is unforgiving if your TLS setup is incomplete. Before enabling it, confirm that the origin presents a valid certificate, that every hostname users may reach is available over HTTPS, and that you are not depending on mixed content or legacy HTTP-only dependencies for page load or authentication flows.
The origin test is especially important because Cloudflare can terminate TLS at the edge while still forwarding to an origin that is misconfigured. If the origin certificate chain, SNI, or host mapping is wrong, browsers that have learned HSTS will refuse to “fall back” to HTTP, and users can be locked out until the HTTPS path is fixed.
For sites with authentication, sessions, or sensitive cookies, a successful HTTPS rollout also depends on making sure the application does not still generate insecure links, callback URLs, or asset references. A browser policy cannot compensate for application content that keeps dragging users back to HTTP.
How to roll it out safely in Cloudflare
Use a staged rollout rather than switching everything on at once. Start by enabling Always Use HTTPS and watching redirect behaviour, certificate validity, and any error spikes. Only after the site is consistently serving clean HTTPS should you enable HSTS, and only then should you consider whether preload is appropriate for your environment.
Keep the scope narrow until you have confidence in the site map. Subdomains, alternate hostnames, and older application paths are common failure points because they are easy to overlook during testing. If any important hostname is still HTTP-only, HSTS can turn a minor inconsistency into a hard failure for returning users.
Cloudflare’s redirect and header settings are easiest to validate alongside a simple browser test matrix, plus a check of origin logs for 301 or 302 loops, certificate errors, and requests that still arrive over HTTP. The point is not just to confirm that the toggle is on, but to confirm that the entire request path remains usable after browsers start enforcing the policy.
Risk and Threat Considerations
HTTPS enforcement reduces downgrade and interception risk, but it also makes pre-existing TLS defects more visible. Once HSTS is active, a broken certificate, an incomplete hostname rollout, or a mixed-content dependency can become an immediate availability issue instead of a recoverable warning.
Failure mechanism: The browser caches the HSTS policy and refuses HTTP fallback, so any origin-side TLS problem, stale hostname, or insecure embedded dependency can block access until the secure path is repaired.
Impact: Users can lose access to the site, authentication flows can fail, and production support may have to restore HTTPS correctness before traffic can recover. In the same way that Cloudflare’s own guidance on Cloudflare Thanksgiving breach 2023 shows how unrotated access material can compound an incident, HTTPS policy failures often become more costly when they are discovered only after a browser policy is already enforced.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, OWASP ASVS and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | Covers HTTPS enforcement and TLS validation for browser-to-site communication. |
| Recommendation — Require HTTPS everywhere and validate TLS configuration before enabling browser-enforced transport policy. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | Applies because HTTPS and HSTS protect data in transit from downgrade and interception. |
| Recommendation — Enforce protected communications for all user-facing traffic and reject insecure transport paths. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Relevant because the question concerns operational use of TLS to protect web traffic. |
| Recommendation — Apply approved cryptographic protection to web traffic and verify the implementation stays valid. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Relevant because TLS misconfiguration and insecure fallback can expose session and credential material in transit. |
| Recommendation — Remove insecure transport paths that could expose credentials or session material during delivery. | ||
Practitioner Guidance
What to verify: Confirm the origin certificate chain, the canonical hostname set, and any login or callback path before enabling HSTS. A green lock on one page is not enough if other subdomains or embedded assets still depend on HTTP.
Decision rule: If the site is still changing frequently, or if any critical hostname has not been validated under HTTPS, keep HSTS short-lived and defer preload. If the HTTPS path is stable end to end, extend the policy gradually and document the rollback plan for certificate incidents.
Practitioner takeaway: Treat Always Use HTTPS as a routing control and HSTS as a browser enforcement control, then only move from one to the other after the full HTTPS path is proven stable.
Related resources from NHI Mgmt Group
- What breaks when a Go application relies on HTTPS redirect logic but does not enforce HSTS consistently?
- How should organisations enforce AI policy compliance across employee and agent use?
- How do you know whether AI-generated integrations are trustworthy enough for security use?
- How do you know if automated remediation is actually safe to use?