HTTP to HTTPS redirects
Configure and verify a same-host HTTPS upgrade so visitors who begin with HTTP are not left on an unencrypted connection.
Reviewed
Check identity
http.https-redirect- Finding
- http.https-redirect.missing
- Severity
- medium
What the check observes
The check makes a bounded request to the HTTP root for the authorized target and evaluates standard redirect status codes.
The redirect location must upgrade to HTTPS and remain on the authorized hostname. Redirect destinations are validated before a follow-up connection.
A non-redirect response, missing location, unsafe destination, or redirect that does not upgrade to HTTPS does not satisfy this check.
Why the result matters
Users and automated clients may still begin with an `http://` URL. Without an upgrade response, that first connection can remain unencrypted.
A consistent edge redirect also reduces ambiguous behavior between application routes, proxies, and legacy listeners.
How to investigate
- 1
Check the exact authorized hostname on port 80 and record the status and Location value without following an unexpected destination.
- 2
Identify whether the HTTP listener is controlled by the application, load balancer, CDN, reverse proxy, or hosting platform.
- 3
Review host canonicalization separately; do not solve an HTTPS upgrade finding by sending users to an unrelated hostname.
Remediation steps
- 1
Configure the public HTTP listener to return a permanent or temporary redirect to the same path on HTTPS for the authorized hostname.
- 2
Preserve expected paths and query behavior, and test applications that depend on callbacks or signed URLs before rollout.
- 3
Remove conflicting application and edge redirect rules that create loops or downgrade hops.
Verify the change
Request representative HTTP paths and confirm each first hop upgrades to HTTPS without a loop, downgrade, or unrelated-host redirect.
Run a new authorized scan and confirm the root redirect check passes.
Limits of this check
- The code-owned check evaluates the root upgrade behavior for the exact target; it does not crawl every application route or prove all generated links use HTTPS.
- A redirect protects the next request, not the confidentiality of data already sent over an initial HTTP request. Applications should avoid accepting sensitive data on HTTP listeners.