Finding: Insecure Redirect Chain
HTTP traffic is redirected, but to another non-HTTPS URL rather than to the secure version — the connection never becomes encrypted.
Last updated August 11, 2026.
What it means
When a browser requests http:// your site, the server is expected to respond with a redirect (a 301, 302, 303, 307, or 308 status) whose Location header points at the https:// version. This finding fires when that redirect happens, but the Location it points to is still http:// — the request gets bounced somewhere, just not to safety. This is often the result of a redirect rule written against a relative path or an old http:// canonical URL that was never updated.
Why it matters
A redirect that never lands on HTTPS means the connection stays unencrypted for the entire visit, even though the site clearly intends to redirect somewhere. Anything submitted over that connection — form data, cookies, login credentials — is readable in transit by anyone positioned between the visitor and the server, such as on a shared or unsecured network. It can also chain into a redirect loop if the destination itself redirects back to HTTP.
What Nivaronix checks
Nivaronix makes a live HTTP request to the domain and inspects the response. If the status code is a redirect (301/302/303/307/308) and the Location header is present but starts with http:// rather than https://, this finding fires. This is a configuration check against the live response — not a vulnerability scan.
Example evidence (illustrative — not live scan data)
GET http://example.com/ HTTP/1.1 HTTP/1.1 301 Moved Permanently Location: http://www.example.com/
How to fix it
Point the redirect destination at the https:// scheme, not another http:// URL — including any intermediate hop (www-normalization, trailing slash, etc.) in the chain.
Nginx
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}Apache
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]Cloudflare
Set the SSL/TLS encryption mode to at least "Flexible" and turn on "Always Use HTTPS" under SSL/TLS → Edge Certificates, or add a Redirect Rule that forces https://as the final destination — don't chain it through another origin-side HTTP redirect.
How to verify the fix
Re-run the website security scanner and confirm the HTTP request now redirects with a Location header that starts with https://.