A redirect drops from HTTPS to plain HTTP

HighConfirmedhttp.redirects.protocol-downgrade

What this check looks for

Part of the journey moves visitors from the secure address back to the insecure one. Whatever they send after that point travels in the clear.

Why it matters

A downgrade throws away the encryption the visitor already had. Cookies, form data and session tokens sent after that hop are readable by anything on the network path — and the browser gave no warning, because it was told to go there.

When the check passes, your report says: “Every hop in the chain stays on HTTPS”.

What it costs your score

When this check fails it removes 30 points from your HTTP score, before the status, confidence and repeat multipliers are applied. HTTP carries a weight of 7 in the overall score.

It shares the http.redirects family ceiling of 45 points: however many findings that family produces, together they cannot remove more than that from HTTP. One underlying problem showing up in several places is still one problem.

Severity: high
Default confidence: confirmed
Status when triggered: fail
Deduction: 30 points
Family cap: http.redirects · 45
Category: HTTP
Module: Http redirects
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Make every redirect target HTTPS.

A downgrade hop discards the encryption the visitor already had.

Find where the http:// URL is generated — application config, a canonical URL setting, or a hard-coded string.
If a proxy terminates TLS, forward X-Forwarded-Proto: https and make the application trust it.
Add HSTS afterwards so a browser refuses the downgrade even if one reappears.

How to confirm it worked

curl -sIL https://‹host›/ | grep -i '^location:' — expect no http:// target

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

nginx

# One hop, straight to the canonical origin. Not http -> https -> www -> path.
server {
	listen 80;
	listen 443 ssl;
	server_name ‹host›;
	return 301 https://www.‹host›$request_uri;
}

Apache

<VirtualHost *:80 *:443>
	ServerName ‹host›
	RedirectMatch 301 ^/(.*)$ https://www.‹host›/$1
</VirtualHost>

Caddy

‹host› {
	redir https://www.‹host›{uri} permanent
}

Cloudflare

Rules → Overview → Create rule → Redirect Rule (path as at 2026-09) → single rule: When hostname equals ‹host›, Static/Dynamic redirect to https://www.‹host›/${http.request.uri.path}, status 301, preserve query string.

Collapse the chain into a single redirect per source host rather than chaining them.
Shown because the response identified Apache. Prefer the virtual host over .htaccess: .htaccess is re-read on every request and its rules run after the virtual host's, which is how these chains get long in the first place.
Cloudflare Redirect Rules run at the edge and apply only to requests that arrive through it. An origin reachable directly — by IP, or through a DNS record that is not proxied — still produces the chain measured here. Fix the origin's own configuration as well.

Technical detail

‹detail›

This is usually a hard-coded absolute URL built with http:// in application code, or a proxy that does not pass X-Forwarded-Proto so the application thinks the request arrived over plain HTTP. HSTS would prevent the browser acting on it, which is a good reason to have HSTS and not a reason to leave the redirect in place.