HTTP to HTTPS redirect remediation guide

What this finding means

SecuTest checks whether TCP port 80 returns a recognized redirect status to HTTPS on the same hostname or its root/www counterpart. Relative redirects and redirects to unrelated hosts do not prove a transport upgrade.

Interpretation boundary Use the exact evidence in your report. SecuTest reports externally observable conditions; it does not assume ownership, exploitability, compromise, or business intent when those cannot be proven remotely.

Associated attack or threat scenario

Threat type SSL stripping and first-request manipulation

How the attack or failure scenario works

SSL stripping is an on-path attack that keeps a victim on HTTP while the attacker communicates with the real site over HTTPS. Without a forced upgrade, the attacker can alter links, inject login forms, or capture data before the browser reaches the protected endpoint.

Conditions and limitations

The victim starts with an `http://` URL or follows an HTTP link.
HSTS is not already cached or preloaded for the hostname.
The attacker can intercept and modify the plaintext request or response.

Why it matters

Security and business impact Serving HTTP without a clear same-site HTTPS redirect leaves first visits exposed to interception, downgrade, and content injection.

Step-by-step fix

Where to make the change

The outermost component emitting the public HTTP response: CDN, reverse proxy, ingress, web server, or application middleware.
Apply the control consistently to normal pages, redirects, error responses, and relevant subdomains.

Remediation procedure

Configure the public edge to redirect every HTTP path to the equivalent HTTPS URL.
Use status 308 or 301 for permanent redirects unless application semantics require another code.
Preserve the hostname, path, and query string and avoid redirecting to unrelated domains.
After validating all HTTPS endpoints, deploy HSTS to protect subsequent and preloaded visits.

Commands and configuration examples

Replace example values with the hostname, selector, IP address, port, provider, or policy values shown in your SecuTest evidence. Review every example before production use.

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

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Enable Always Use HTTPS and verify no conflicting redirect rule sends traffic back to HTTP.

Verify the fix

Run `curl -I http://example.com/path?x=1`.
Confirm the status is a redirect and `Location` begins with the intended HTTPS origin.
Test root, www, application, error, and API hostnames separately.
Verify there is no redirect loop or temporary downgrade.

Confirm the externally visible result

After DNS, CDN, certificate, mail, or application propagation completes, run a fresh SecuTest scan and compare the new evidence with the original finding.

Re-scan your domain

Common mistakes

Redirecting only `/` while deeper paths remain on HTTP.
Sending users to an unrelated marketing domain instead of the equivalent secure URL.
Creating an HTTP/HTTPS redirect loop at the CDN and origin.

HTTP to HTTPS redirect