Password on HTTP

Element Code: SE-019

What this issue actually means

This check fires when a page that collects a password (a login form, a registration form, a checkout, an account settings screen) is loaded over http:// instead of https://, or when the page itself is HTTPS but the form's action attribute posts to an http:// endpoint. Either way, the password the user types leaves their browser unencrypted. Anyone sitting on the same coffee-shop Wi-Fi, a compromised router, or a hop somewhere between the visitor and your server can read those credentials in plain text. There is no clever caveat here. Cleartext passwords on a network are exactly as bad as they sound.

People often assume the padlock in the address bar is a cosmetic nicety. It is not. TLS does two jobs at once: it encrypts the payload so eavesdroppers see gibberish, and it authenticates the server so the visitor knows they are actually talking to you and not a machine that quietly inserted itself in the middle. Strip that away on a password page and you have handed attackers both a wiretap and an impersonation kit.

Why search engines and browsers care

Google has treated HTTPS as a lightweight ranking signal since 2014, per its own Webmaster Central announcement. On its own that nudge is small. The real damage is downstream. Chrome, Firefox, Safari and Edge all flag any HTTP page containing a password or credit-card field with a visible "Not secure" warning, and some versions actively block submission or throw a full interstitial. That warning tanks form completion. Users who came to sign in bounce instead, and a page nobody can convert on is a page that slowly loses its reason to rank.

There is a crawling angle too. When you finally migrate to HTTPS but leave HTTP versions reachable, you create duplicate URLs, split link equity across two protocols, and force Google to guess at canonicals. A clean, forced HTTPS setup removes that ambiguity entirely.

How the exposure happens, start to finish

The insecure segment is any leg of the journey that runs over HTTP. It does not matter that your database is locked down or that you hash passwords at rest. The password is stolen in transit, long before hashing ever happens.

How to detect it

Reproducing this takes about a minute, but you want systematic coverage across the whole site, not just the one form you remembered.

• The browser itself: load the login page, open DevTools, watch the Security panel. Chrome will label the page "Not secure" and log mixed-content warnings in the Console. Inspect the form element and read its real action URL, not the one you assume is there.
• Screaming Frog SEO Spider: crawl the site and use the Security tab, which surfaces HTTP URLs, mixed content, and "form on HTTP" style issues. Filter for pages still resolving on http://.
• Sitebulb: its security hints flag insecure forms and mixed content with clear severity ratings, useful when you need a report a stakeholder will actually read.
• Google Search Console: not a direct detector for this, but the HTTPS report and coverage data show whether HTTP URLs are still indexed, which is your clue that redirects are incomplete.
• Server logs: grep access logs for requests hitting port 80 on form-handling endpoints. Real traffic on HTTP is your proof that the exposure is live, not theoretical.

How to fix it, step by step

1. Install a valid TLS certificate for the domain and every subdomain that serves forms. Let's Encrypt is free and automatable, so cost is not an excuse.
2. Serve the form page over HTTPS and set the form action to an absolute or protocol-relative HTTPS URL. Confirm the POST target is HTTPS, because an HTTPS page posting to an HTTP endpoint is still wide open.
3. Force redirects. Add a 301 from every HTTP URL to its HTTPS equivalent at the server level. Do it once, globally, rather than page by page.
4. Fix mixed content. Update hardcoded http:// references to images, scripts, and stylesheets. A single insecure script can strip the padlock and reintroduce risk.
5. Send HSTS. Add the Strict-Transport-Security header so browsers refuse HTTP for your domain going forward, closing the first-request downgrade window.
6. Re-crawl and verify. Run Screaming Frog again, confirm zero HTTP form pages remain, and load the page in an incognito window to check for a clean padlock.

Good versus broken

Reference: where credentials leak

What "good" looks like

Every URL that touches a credential resolves on HTTPS, the form posts to an HTTPS action, HTTP requests 301 to their secure twin, HSTS is live, and a fresh crawl returns no insecure-form or mixed-content flags. The padlock shows on the first load with no downgrade path. Once that is true, this check stays green and you never have to think about it again.

FAQ