Password Input on an HTTP Page: How to Fix This Now

What this check flags

This audit catches a form that contains a password input and is either served over plain HTTP, submits to an HTTP endpoint, or both. In plain terms: somewhere on the site there is a login or sign-up box where the page in the address bar starts with http:// instead of https://, or the form quietly sends what the user types to an unencrypted address.

The crawler looks at two things. First, the protocol of the page holding the form. Second, the URL in the form's action attribute, which is where the typed data actually goes when someone clicks submit. If either one is HTTP, the check fires.

The real risk

When a password travels over HTTP, it travels in clear text. There is no encryption wrapping it. Anyone sitting between the visitor and your server can read it with free, widely available packet-sniffing tools. That includes whoever runs the coffee-shop Wi-Fi, a compromised router, or an attacker performing a man-in-the-middle attack on the local network. The credential is just sitting there in the open, readable as plain words.

Honestly, a login form still sitting on plain HTTP in this era is a damn embarrassing thing to ship, because the cost of fixing it dropped to roughly zero years ago. Free certificates have been a one-click affair for a long time, and browsers have been warning users about exactly this since early 2017.

The browser reaction is the part you cannot hide from. Chrome and Firefox both mark any page carrying a password field over HTTP as "Not Secure" right in the address bar. Chrome 86 went further and started prominently warning on, and interfering with, insecure forms even when the page itself loads over HTTPS but submits to an HTTP target. Visitors see a red flag at the exact moment you are asking them to trust you with a password. Many simply leave.

Why this is high severity

Most technical-SEO issues cost you a bit of crawl efficiency or a ranking nudge. This one leaks credentials. It is rated high severity because the failure mode is direct account compromise, not a missed keyword. Reused passwords make it worse: a single intercepted login can unlock a visitor's email, bank, and everything else they recycle that password across.

There is a search angle too. HTTPS is a confirmed Google ranking signal, and a "Not Secure" label tanks the trust signals that drive conversions. But the security exposure alone is enough to treat this as drop-everything urgent.

How to fix it

You need both halves. Serve the page over HTTPS AND set the form action to HTTPS. Fixing only one leaves a real hole. A man-in-the-middle who controls an HTTP page can inject JavaScript that grabs the password before it ever reaches your secure endpoint, so an HTTPS action on an HTTP page is not safe. And an HTTPS page that posts to an HTTP action ships the credential in clear text on submit.

Step one, install a TLS certificate and serve the whole site over HTTPS. A free certificate from Let's Encrypt works fine.

Step two, force every HTTP request to HTTPS with a 301 redirect:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Step three, make sure the form action is absolute HTTPS or a root-relative path that inherits the secure protocol:

<!-- Bad: explicit http target -->
<form action="http://example.com/login" method="post">

<!-- Good: explicit https target -->
<form action="https://example.com/login" method="post">

<!-- Also fine: relative path, inherits https -->
<form action="/login" method="post">

Step four, add HSTS so browsers refuse to talk to your site over HTTP at all going forward:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

How to diagnose it

Load the flagged page and check the address bar. If you see "Not Secure" or http://, that is half your answer. Then open developer tools, find the form, and read its action attribute directly. View source and search for action="http: to catch hardcoded insecure targets that redirects will not save you from.

In Chrome DevTools, the Security panel and Console will warn you about mixed content and insecure form submissions. A site crawler that surfaces password-on-HTTP findings, like the one that produced this report, will list every offending URL so you are not hunting blind.

Common mistakes

The classic trap is an HTTPS page that posts to an HTTP endpoint. The padlock looks fine, the team assumes the job is done, but the form action still points at http:// and the credential goes out in clear text on submit. Always check the action, not just the address bar.

The mirror-image mistake is leaving an HTTP login page in place while pointing its action at HTTPS and calling it secure. It is not. The page itself can be tampered with in transit. Both the page and the submission target must be HTTPS.

Other repeat offenders: a redirect that covers the homepage but misses the login subdirectory, cached HTTP versions of the form, hardcoded http:// links inside templates, and embedded login iframes loaded over HTTP. If the form lives in an iframe, that iframe has to be HTTPS too.

FAQ