Does your site still answer over plain HTTP?

Type http://yoursite.com into a fresh tab. No s. Just the bare address, the way half your visitors actually reach you. Does the bar snap to https:// before the page paints, or does your server hand back a real page over plain HTTP?

That's the test nobody runs after the cert goes in. You set up HTTPS ages ago, the padlock is there, the site loads cleanly over https://, and you call it done. But people type yoursite.com into the bar, follow old links, or let an app prepend http:// for them. If your server still answers those requests with content instead of bouncing them to HTTPS, you have a hole the padlock hides completely.

The request nobody encrypts

http:// traffic is plaintext. There's no weaker encryption here to fall back on, there's just none at all. Every byte travels in the clear, readable and writable by anything sitting on the path between the visitor and you.

That path is more crowded than you think. The coffee-shop Wi-Fi. The hotel network. The airport portal that injects its own banner into pages. A compromised home router. Any of these can sit in the middle, watch the plaintext request go by, and answer it themselves before your server ever hears about it. The visitor asked for your site over HTTP. The network decided what your site says.

So a stranger on the same network types nothing special. They run a tool that's been around for a decade, point it at the open access point, and wait. When your visitor's browser sends that first http:// request, the tool returns a page that looks exactly like yours, with the login form wired to the attacker. Or it strips the redirect that would have upgraded them to HTTPS and keeps the whole session on plaintext. The visitor sees your layout, your logo, your copy. They do not see that the connection was never yours.

Mixed content: the leak inside the lock

There's a quieter version of this that lives on pages already served over HTTPS. You load the page securely, but somewhere in the markup a script, image, or stylesheet is pulled over http://. A hardcoded http://cdn.example.com/widget.js. An old analytics snippet. A font from a provider you forgot about.

That single plaintext request is a window. Browsers block the most dangerous mixed content now, active scripts especially, but they do not block all of it, and a blocked request is still a request that announced itself in the clear. An attacker on the path can swap a passively loaded asset, and any sub-resource that does slip through executes with your origin's trust. The padlock stays up. The page is no longer entirely yours.

How to check in two minutes

You don't need any tooling for the first pass.

1. Type your domain with http:// in front of it, explicitly. http://yoursite.com.
2. Watch the address bar. It should snap to https:// before the page paints. If the page loads and stays on http://, your server answered a plaintext request with real content.
3. On a page you serve over HTTPS, open developer tools, go to the Console, and reload. A mixed-content warning naming an http:// resource means you're loading something insecurely.

This is the rare finding where standing outside is the whole point. A stranger on the network only ever sees your site from the outside, so that's exactly where SurfaceCheckr stands: it sends the bare http:// request, follows whatever your server hands back, and tells you whether you got a clean redirect or a live plaintext page. It reads the mixed-content references in your HTML the same way. No login, no payloads, nothing touching your backend, so it won't tell you about your authenticated routes the way a pentest would. For a downgrade this is all you need to know.

The fix is one redirect

Every http:// request should get a 301 straight to its https:// equivalent, before any content is sent. Most stacks do this in a few lines, and the right layer is usually your web server or edge, not your app code.

# nginx: listening on 80 and serving the site
server {
listen 80;
server_name yoursite.com;
root /var/www/site;   # plaintext page goes out
}

Once HTTP is redirecting cleanly, the next gap is the first request itself, the one that happens before the browser knows to use HTTPS at all. That's what a missing HSTS header leaves open, and it's worth closing in the same sitting. While you're in the headers, fix any mixed content your pages still pull over http:// so the lock means what it says.

Type your own domain with http:// in front of it right now. If the page loads, so can a stranger's version of it.