← All checks
SecurityTypical severity: Medium

HTTPS Redirect Checker

Checks that the HTTP version of your site properly redirects to HTTPS instead of serving unencrypted.

What it checks

This checker verifies that when someone visits the HTTP version of your site, the server redirects them to HTTPS instead of serving the page unencrypted. It confirms the insecure door always leads to the secure version. It only observes the redirect behavior.

Why it matters

If the HTTP version is served as-is, visitors may browse your site without encryption and expose their data without noticing. It also enables attacks that intercept the connection before it reaches HTTPS. A proper redirect ensures all traffic ends up protected.

How to fix it

Configure your server or host so every HTTP request issues a permanent redirect to HTTPS. Combined with the HSTS header, the browser will go straight to the secure version on future visits. Many platforms offer this redirect with a single checkbox.

How this check works

Scanaris requests your page over http://, without the s, without following redirects, and looks at what the server answers. If it returns a redirect code (301, 302, 307 or 308) to an https:// URL, all good. If it answers 200 and serves the page in the clear, it opens a medium-severity finding: the unencrypted version of your site exists and works. If it redirects but the destination is still http:// (for example, from the root to http://www), it opens a low-severity one: the redirect chain has an unencrypted link. Only the scanned URL is tested; the behaviour should be the same on every route, not just the home page.

Why it matters

As long as an HTTP version answers, any old link, any address typed by hand and any public network can bring the user to your site without encryption. In that state, whoever controls the network (the airport wifi, a malicious provider) reads what is sent and can modify the page before it arrives. It is the basis of man-in-the-middle attacks. A 301 to HTTPS closes that door on the first request, and HSTS closes it for all the following ones.

How to fix it depending on your hosting

  • Vercel, Netlify, Cloudflare Pages, Railway, Render: the redirect comes enabled. If you see the finding, usually the domain points at another server or there is a proxy in front answering over HTTP.
  • Cloudflare as a proxy: enable "Always Use HTTPS" and set the SSL mode to "Full (strict)". With "Flexible", the leg between Cloudflare and your server travels unencrypted.
  • nginx:
server {
  listen 80;
  server_name yourdomain.com www.yourdomain.com;
  return 301 https://$host$request_uri;
}
  • Apache: in the port 80 VirtualHost, Redirect permanent / https://yourdomain.com/.
  • Express behind a proxy: a middleware that checks req.headers['x-forwarded-proto'] !== 'https' and answers with res.redirect(301, 'https://' + req.headers.host + req.url), with app.set('trust proxy', 1).

Use a 301 or a 308 (permanent) and not a 302: search engines consolidate authority on the HTTPS version and browsers cache the jump. Then add the HSTS header, which the weak HSTS check measures, so the browser does not even try HTTP next time.

Check it is fixed

curl -sI http://yourdomain.com | grep -iE "^HTTP|^location"
curl -sI http://yourdomain.com/any-page | grep -iE "^HTTP|^location"
curl -sI http://www.yourdomain.com | grep -iE "^HTTP|^location"

All three must answer 301 or 308 with a Location starting with https://. If the second does not redirect, your rule only covers the home page.

Frequently asked questions

Is having HTTPS enabled not enough?

No. Having a certificate means the secure version exists; the redirect means the insecure one is not used. Without it, both coexist.

Why 301 and not 302?

The 302 is temporary: browsers request the HTTP version again every time and search engines do not transfer the authority. The 301 (or the 308, which also preserves the method) is the signal that the change is definitive.

My API does not need HTTPS, only my app uses it.

It does: tokens and your users' data travel through that API. And if the app calls it over HTTP from an HTTPS page, the browser blocks it as mixed content.

Check it on your site

Scan your site free and see if this and 44 other checks pass, with a fix prompt for every issue.

Scan my site free

From the blog

Related checks