Your login form has a padlock. Does the password actually travel encrypted?

The padlock in the address bar tells you the page arrived over HTTPS. It says nothing about where the page sends your password when you hit submit. Those are two different things, and the gap between them is one of the oldest, quietest credential leaks on the web: a login form rendered on a secure page that posts to an insecure one.

Look at the form's action. If it starts with http://, the browser will collect the password the visitor typed and send it across the network in cleartext, padlock or no padlock. The encrypted page lulls everyone, the visitor sees the lock, the developer sees HTTPS in the URL, and the one request that carries the actual secret goes out in the open. Anyone sharing that network, the café Wi-Fi, the hotel router, a compromised hop upstream, reads the username and password as plain text.

Two shapes, one outcome

This finding shows up in two ways, and they fail differently, so it's worth separating them.

The first is the mixed-form case: an HTTPS page with a password field inside a <form action="http://...">. The page is secure; the submission target is not. The browser may warn on submit in some cases, but plenty of users click through, and automated logins and password managers don't see the warning at all.

The second is simpler and worse: the whole page is served over plain HTTP and contains a login form. Here there's no padlock to give false comfort, but the deeper problem is that an attacker on the network doesn't even need to wait for the submission. They can rewrite the page in flight, point the form wherever they like, inject a keylogger, swap the whole login for their own. When the page itself isn't encrypted, you can't trust anything on it, including the form that's about to take a password.

Why a modern site still does this

You'd think HTTPS-everywhere killed this years ago. It mostly did, which is exactly why the survivors are easy to miss.

The usual cause is a hardcoded absolute URL. Someone wrote action="http://yoursite.com/login" back when the site was HTTP, the site moved to HTTPS, and the form kept its old absolute action because nobody re-checked it. Or a legacy login lives on a subdomain or a path that never got the TLS treatment the main site got. Or a reverse proxy terminates TLS and an internal redirect quietly drops back to http:// for one hop that happens to be the auth POST. The form looks fine in the browser, the login works, and the cleartext submission is invisible unless you read the markup or watch the network tab. It's the kind of thing that passes every click-through test and fails the one that matters.

Make every credential path HTTPS, end to end

The fix is to ensure the password never travels over anything but TLS, from the page that collects it to the endpoint that receives it.

<!-- secure page, insecure submission target -->
<form action="http://yoursite.com/login" method="post">
<input name="email">
<input name="password" type="password">
</form>

Use a relative action (/login) or an explicit https:// one so the submission can never drop to cleartext. Serve every page that contains a login form over HTTPS, with no HTTP version answering at all. Then add Strict-Transport-Security so the browser refuses to make a plaintext request to your origin in the first place, and upgrade-insecure-requests in your CSP as a backstop that rewrites any stray http:// reference to https:// before it's fetched.

The reason this is catchable from outside is that the form markup and the page's scheme are both right there in what the server serves. SurfaceCheckr reads each form on the page and flags this only when one form block holds both a password input and an http:// action, or when the page itself arrives over plain HTTP and carries a login. The check is scoped to a single form at a time on purpose, it never raises the alarm from a page-wide coincidence of "there's a password somewhere and an http link somewhere else," because that scoping is what keeps it honest. It reads the markup and stops; it never submits the form or sends a credential. For the broader version of this, where any resource on an HTTPS page loads over HTTP, mixed content and what the padlock hides is the wider read, and why a missing HSTS header leaves a gap on the very first visit is the header that slams this door for good.