The fix, in one snippet
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now sends GET http://<host>/ on port 80 and follows up to five redirects, recording each status code and Location header. The check passes when the chain ends at an https:// URL on the same host, using a permanent status (301 or 308). It fails when port 80 answers 200 with page content, when the redirect points to another plain-HTTP URL, or when the chain never reaches HTTPS. Two softer conditions are reported as notes rather than failures: a temporary redirect (302 or 307), which browsers do not cache, and a first hop that goes to HTTPS on a different host (for example http://example.com straight to https://www.example.com), which is valid but disqualifies the domain from HSTS preloading. If nothing listens on port 80 at all, the check records that as informational: no downgrade surface, but users typing the bare name in older browsers will get a connection error.
Why it matters
The first request a browser makes when someone types example.com is still plain HTTP unless the domain is preloaded or the browser has seen an HSTS header before. That single request is the foothold for SSL stripping: an attacker on the path answers it themselves, serves a rewritten copy of your site over HTTP, and proxies the real HTTPS site behind the scenes, harvesting logins and cookies as they pass. If port 80 serves full content, the whole site is usable without encryption and nothing forces a user onto the secure version. Cookies lacking the Secure flag are sent on that first request. The HSTS guide covers the attack and the layered defence in detail.
How to fix it
Redirect every HTTP request permanently to the same path on HTTPS, then add an HSTS header on the HTTPS side so returning browsers skip HTTP entirely. nginx:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
Apache (mod_rewrite is not needed for a whole-host redirect):
<VirtualHost *:80>
ServerName example.com
Redirect permanent / https://example.com/
</VirtualHost>
Express behind a reverse proxy that sets X-Forwarded-Proto:
app.set('trust proxy', 1);
app.use((req, res, next) => {
if (req.secure) return next();
res.redirect(301, 'https://' + req.headers.host + req.originalUrl);
});
On Cloudflare, enable Always Use HTTPS under SSL/TLS > Edge Certificates; the edge answers port 80 with a 301 before the request reaches your origin. Keep the redirect on the same hostname (apex to apex, www to www) and do the canonical www/non-www redirect as a second hop over HTTPS, which is what the preload list requires.
Where this fits
HTTP redirects to HTTPS is check 5 of 12 that the website vulnerability scanner runs under transport security (https / tls), ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits Deprecated TLS versions accepted (1.0 / 1.1) (high), where the server still completes handshakes with TLS 1.0 or TLS 1.1. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
HTTP redirects to HTTPS closes one route in. Immediately below it: Certificate key strength, where the certificate's public key is weaker than current guidance: An RSA key shorter than 2048 bits, or a DSA key; Certificate signature algorithm, where a certificate in the chain is signed with SHA-1, MD5 or another broken hash; Strict-Transport-Security (HSTS), where the HTTPS response carries no Strict-Transport-Security header, or its max-age is too short to protect returning visitors.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Exposed .env configuration file, where a .env configuration file is served from the web root, and Exposed .git repository, where the site's .git directory is reachable over HTTP. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: HTTP redirects to HTTPS (high severity)
Scanner check id: http-redirects-to-https
What this check tests: Port 80 serves page content instead of redirecting to HTTPS, or the redirect chain is wrong. Visitors who type the bare domain, or follow an old http:// link, stay on an unencrypted connection.
The rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.