HTTP to HTTPS redirects

Your HTTPS site can be flawless and still serve plain HTTP on port 80 to anyone who asks. That first unencrypted request is the finding.

A site can serve HTTPS perfectly and still answer plain HTTP on port 80. Someone who types example.com into a browser sends an unencrypted request before anything else happens. Without a redirect, that request, its path, and its cookies go out in the clear on whatever network the visitor is on.

SSLBoard checks what the HTTP listener does and flags hosts that listen on port 80 and are confirmed not to redirect to HTTPS. If bot protection, rate limiting, or a connection error prevents verification, the result is unknown and does not count as a failure. The HSTS check covers the other half of the same problem.

Interpreting the result

A redirect finding means port 80 was reported as listening and no redirect to HTTPS was confirmed. Look at the response and where it points.

Two things it does not mean:

Port 80 not listening at all is a different configuration, not this finding.
An unknown or failed HTTP check proves neither behavior. The missing-redirect table can include a listening host whose redirect result simply is not true, so read the evidence when the probe was incomplete.

Decide per service, not per domain

For a public website that visitors type by hand, redirect to HTTPS. That is uncontroversial.

APIs, health checks, and machine-to-machine endpoints can be a different story. A client that follows redirects silently may be worse than one that fails loudly. Look at the actual route and the actual clients before applying a blanket rule.

A redirect and HSTS are not substitutes

They cover different moments:

The redirect handles a plain HTTP request that has already left the browser.
HSTS stops the browser from sending that request at all, but only for a browser that has already seen your policy over HTTPS.

So the redirect protects the first visit, and HSTS protects every visit after. See HSTS.

Verify after deployment

Run a fresh scan and confirm the finding is gone for the affected hosts. Then check two things the finding itself will not tell you: that the redirect target is the site you meant, and that it does not loop.

One last thing: a correct redirect does not fix a certificate error waiting at the destination. It just gets the visitor there faster.

Questions people ask

My site works on HTTPS. Why is there a redirect finding?

Because port 80 is answering separately. A visitor who types your domain without a scheme sends a plain HTTP request first, and if nothing redirects it, that request and everything in it travels unencrypted.

Is a redirect the same as HSTS?

No, and you want both. A redirect answers an HTTP request that has already been sent in the clear. HSTS tells the browser to never send that request in the first place, but only after it has seen your policy once over HTTPS.

What if port 80 is not listening at all?

That is a different configuration and not the same finding. The check flags hosts that are listening on port 80 without a confirmed redirect to HTTPS.