HTTP Not Redirecting to HTTPS: Configure a Safe Redirect

In one paragraph

HTTP not redirecting to HTTPS means the site can serve content over an unencrypted connection instead of sending visitors to its secure version. Configure a server-side redirect to the intended HTTPS URL, preserve the path and query string, and test every supported hostname. Add HSTS only after HTTPS works reliably; a redirect alone cannot protect an initial HTTP request from an active network attacker.

Why it matters

HTTPS encrypts the connection and authenticates the server through its certificate. Serving a parallel HTTP version allows an unencrypted route to content that should be delivered securely. An attacker on the network path may observe or modify that traffic.

Browser HTTPS-first features can reduce exposure, but behaviour depends on browser settings, navigation type, and fallback conditions. Do not assume every visitor tries HTTP first, or that modern browser upgrades remove the need for a correct server configuration.

A redirect helps visitors and crawlers converge on the preferred HTTPS address. It does not encrypt the request that already went to HTTP. HSTS provides a separate browser instruction to use HTTPS for subsequent applicable requests, while preloading can extend that protection to first contact for included domains.

How WebAuditOS evaluates this finding

The supplied site-wide check probes HTTP when the scanned origin is HTTPS. A redirect to the HTTPS origin passes; serving HTTP content without a redirect fails. A refused connection on port 80 also passes the documented check. Timeouts and other inconclusive probe failures are not graded, as are origins not using HTTPS.

A closed port is not evidence that HTTPS redirection works. It may be an intentional configuration, but visitors or clients attempting HTTP can receive a connection error. The check's pass condition describes the observed transport behaviour, not every usability or canonicalisation requirement.

How to fix it

1. Confirm HTTPS is healthy before redirecting. Check the certificate, hostname coverage, application routing, assets, and authentication on the final destination.
2. Put the redirect at the edge where possible: CDN, load balancer, or web server. Redirecting before application startup avoids unnecessary work and covers paths that never reach a framework handler.
3. Use a permanent server-side redirect for the production scheme migration. Google treats 301 and 308 as permanent redirect signals. Prefer 308 when method and body preservation is required by your supported clients. Do not encourage clients to send passwords over HTTP merely because the redirect can preserve a POST.
4. Preserve the requested resource. For a single canonical hostname, an illustrative nginx server block is:

server {
    listen 80;
    server_name example.com www.example.com;
    return 308 https://example.com$request_uri;
}

Replace example.com with your intended production hostname and integrate the rule with your existing virtual hosts. This example does not cover IPv6 listeners, certificate setup, or challenge-specific routing. Avoid building destinations from unvalidated arbitrary Host values.

5. Avoid unnecessary redirect chains. Where your configuration and other requirements permit it, redirect directly to the final HTTPS canonical URL, combining host and scheme normalisation. Some HSTS preload requirements have their own same-host redirect expectations; verify those if preloading is planned.
6. Check proxy handling. Redirect loops commonly occur when a TLS-terminating proxy forwards HTTP internally and the application fails to recognise the original HTTPS connection. Trust forwarded scheme information only from the intended proxies.
7. Verify representative URLs without automatically following redirects, then inspect the complete chain:

curl -I http://example.com/products?ref=test
curl -IL http://example.com/products?ref=test

Confirm Location, status, final host, preserved path, and expected query handling. If your server treats HEAD differently, repeat using a normal GET. Update internal links, canonicals, and sitemap entries to the final URLs.

What the fix can break

Load balancer health checks and older API clients may treat redirects as failures or handle method changes unexpectedly. Inventory active clients and update their configured URL to HTTPS directly.

Certificate renewal deserves a separate test. Let's Encrypt HTTP-01 starts on port 80 and follows supported HTTP or HTTPS redirects; a redirect alone does not necessarily break it. Renewal fails if the challenge cannot be reached or the destination does not serve the expected token. Test your ACME renewal flow rather than exempting paths blindly.

Permanent redirects may be cached. Validate rules on staging or a limited deployment first, especially broad path mappings. HSTS adds a longer-lived browser commitment and should be rolled out only after transport and subdomain requirements are understood.

Questions

Should HTTP-to-HTTPS redirects use 301 or 308?

Both are permanent redirects. 308 preserves the request method and body; 301 permits historical POST-to-GET behaviour. Choose deliberately and configure clients to request HTTPS initially.

Should scheme and hostname redirects always be separate?

No. Direct redirection to the final destination generally avoids needless hops. Check any specific HSTS preload requirements before combining rules for that use case.

Why does a closed port 80 pass WebAuditOS?

The documented rule treats an actively refused HTTP connection as a pass because it observes no served plaintext content. It does not claim that HTTP visitors receive a working redirect.

What should I review next?

Review missing HSTS, cookies without Secure, and the security headers guide. These controls address risks the redirect does not eliminate.