Enforce HTTPS with HSTS

TLS protects an HTTP connection after the browser starts HTTPS. A plain HTTP request sent before a redirect is different: it has no TLS protection, so a network attacker can alter the response and prevent the redirect from reaching the browser.

HTTP Strict Transport Security (HSTS) gives a site a browser-enforced transport rule. After receiving a valid HSTS policy over HTTPS, a supporting browser remembers that the host must use HTTPS for a defined period. Future HTTP navigation attempts are upgraded locally before an insecure request is sent.

The core model is:

HTTPS response with HSTS
  -> browser stores host policy
  -> later HTTP URL
  -> browser changes scheme to HTTPS locally
  -> TLS connection starts

This moves an important transport decision from an unauthenticated HTTP response into browser state established through HTTPS.

Send the policy only over HTTPS

A typical response header is:

Strict-Transport-Security: max-age=31536000

max-age is measured in seconds. A value of 31536000 represents one year.

Browsers process this header only when it arrives through a secure connection. Sending it on an HTTP response does not establish HSTS, because an attacker on that connection could insert, remove, or alter the header.

Configure the HTTPS virtual host or edge service to emit the header. An HTTP endpoint can still redirect traffic to HTTPS, but that redirect is not the mechanism that establishes HSTS.

A useful deployment check is:

HTTP request:
  redirect to HTTPS

HTTPS response:
  valid TLS
  Strict-Transport-Security header present

Treat the first visit as a separate risk

HSTS stored by a browser protects later visits. It cannot retroactively protect an initial HTTP request made before the browser has a policy for the host.

Consider a person entering:

http://portal.example

Without prior HSTS state, the browser may send that HTTP request over the network. A hostile access point could answer before the legitimate server and keep the session on HTTP.

After the browser has received an HSTS policy from https://portal.example, the same HTTP URL is handled differently: the browser upgrades it to HTTPS before contacting the site over HTTP.

This distinction matters when describing the control. HSTS is strong stateful protection after policy acquisition, not a universal guarantee for every first contact.

Choose max-age as a commitment

A long max-age gives durable protection, but it also commits the host to working HTTPS for that period.

Start with a short value during rollout:

Strict-Transport-Security: max-age=300

Then increase it after confirming that HTTPS works across normal traffic paths:

Strict-Transport-Security: max-age=86400

Later, move to a long production value:

Strict-Transport-Security: max-age=31536000

The exact rollout periods depend on the service and operational maturity. The important point is to increase the commitment deliberately.

Do not deploy a year-long policy on a host that still depends on occasional HTTP access, has unstable certificate automation, or contains services that cannot support HTTPS.

Use includeSubDomains only with full coverage

This directive extends the policy to subdomains:

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

If example.com sends this policy, a supporting browser also requires HTTPS for hosts beneath that domain, such as:

api.example.com
assets.example.com
old.example.com

That can close gaps where a sensitive parent domain uses HTTPS but a related subdomain remains reachable over HTTP.

It can also break forgotten systems. Before enabling includeSubDomains, inventory active and delegated subdomains, internal entry points exposed to browsers, vendor-hosted names, legacy services, and certificate coverage.

A subdomain operated by another team is still affected by the parent policy in the browser. Organizational boundaries do not cancel DNS hierarchy.

Understand preload as a separate mechanism

Browser preload lists can address the first-contact gap for selected domains. A browser shipped with a domain on its HSTS preload list can apply HTTPS-only behavior before that browser has ever visited the site.

Preload is not activated merely by adding a token to a header. Operators must satisfy the current preload program requirements and submit the domain through the applicable process. Removal can also take time because browser releases must propagate updated lists.

A preload-oriented header often resembles:

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

Treat preload as a high-commitment deployment choice. Confirm HTTPS support for the registrable domain and relevant subdomains before entering a preload program. Check current program requirements directly because eligibility rules can change.

Keep certificate errors fatal

HSTS is more than automatic URL rewriting. For an HSTS host, browsers also prevent users from bypassing certain TLS certificate errors through the normal click-through flow.

That behavior is essential. An attacker who can present an invalid certificate should not be able to turn a transport warning into an optional choice for a host that has declared strict HTTPS.

Operationally, this raises the cost of certificate mistakes. Monitor certificate issuance, renewal, hostname coverage, expiration, and edge deployment. A broken certificate on an HSTS host can make the service unavailable to affected browsers until the TLS configuration is repaired.

Security policy and certificate operations therefore belong in the same deployment plan.

Apply HSTS at the correct response layer

Many systems have several HTTP layers:

browser
  -> CDN
  -> load balancer
  -> reverse proxy
  -> application

The browser only sees the final response delivered by the public-facing path. It does not matter that an internal application generated an HSTS header if an intermediary strips it before delivery.

Test the externally visible HTTPS response. Check representative hostnames and response classes, including redirects, errors, and application pages.

A practical rule is to set HSTS at a layer that consistently controls public HTTPS responses. In some architectures that is the CDN or reverse proxy. In others it is the application platform. Avoid conflicting policies emitted by multiple layers.

Do not confuse HSTS with redirect logic

A server-side redirect might look like:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

This is useful for ordinary navigation, but the browser must first receive the HTTP response. That exchange can be modified on an untrusted network.

With stored HSTS state, the browser does not depend on that redirect for the protected host. It changes an HTTP navigation to HTTPS before sending the insecure request.

Keep redirects for compatibility and canonical routing, but do not describe them as equivalent to HSTS.

Account for ports and non-browser clients

HSTS is a browser transport policy defined around HTTP origins and hostnames. It is not a generic firewall rule and does not force every network client to use TLS.

Command-line programs, API SDKs, embedded clients, and custom HTTP stacks may implement different behavior or none at all. Protect machine-to-machine traffic through explicit HTTPS endpoints, certificate verification, client configuration, and network controls appropriate to that system.

Port handling also deserves testing. Browsers apply HSTS scheme upgrades according to specification rules, but an application exposed on unusual ports can still fail if the corresponding HTTPS service is not available.

Do not use HSTS as a substitute for closing unintended plaintext listeners.

Remove a policy deliberately

A host can ask a browser to remove stored HSTS state by sending:

Strict-Transport-Security: max-age=0

That response itself must arrive over valid HTTPS.

This is useful for policy rollback, but it does not instantly reach browsers that do not revisit the host. It also does not provide a quick escape from preload status.

Plan reversibility before long-duration deployment. If a service might need to return to HTTP, a long HSTS commitment is a poor fit.

Test the policy from the outside

Header presence is only one part of validation. Test the complete behavior.

A compact matrix includes:

Also inspect CDN rules, alternate domains, redirects, and error responses. Automated checks can verify the header on public endpoints, while browser tests can confirm actual policy behavior.

Deploy with an operational checklist

Before using a long HSTS policy, confirm these properties:

• Public pages and assets work over HTTPS.
• Certificate renewal is automated and monitored.
• HTTP requests redirect to the intended HTTPS location.
• The HSTS header appears on externally visible HTTPS responses.
• max-age has been increased through a controlled rollout.
• Every affected subdomain supports HTTPS before includeSubDomains is enabled.
• Preload requirements and removal constraints have been reviewed before submission.
• Alternate hostnames and legacy browser-facing services have been inventoried.
• Monitoring detects missing headers and certificate failures.
• Teams understand that HSTS does not secure clients that ignore the policy.

HSTS is most effective when treated as a durable browser security contract rather than a decorative response header. Establish the policy over valid HTTPS, expand its lifetime after operational checks, extend it to subdomains only with full coverage, and approach preload with care. Combined with reliable TLS operations, this keeps browser traffic on the authenticated transport path even when a user follows an HTTP URL.