Login form over unencrypted HTTP
What it is
Somewhere on your site there is a form with a type="password" field whose action (action=) points to an unencrypted http:// URL. The password you type travels across the network in the clear.
This typically shows up on:
- Older login screens (often hosting admin panels, intranets, archived installations).
- A site that has HTTPS, but contains a
<form action="http://...">with a hardcoded HTTP URL inside. - A subdomain (
old.example.com,admin.example.com) that has no certificate.
Why it is a problem
When a user enters a password and presses Enter, the browser sends it in plain text. Anyone in between (an untrusted Wi-Fi network, the ISP, a hosting neighbor, a compromised router) can read the password. If the form is on a different hostname than the page itself, the browser will warn — but users typically just click “Continue”.
Since version 86, Chrome shows “This form is not secure” right below the input. Conversion drops and people stop signing up.
How to fix it
Step 1 — fix action=
Find all <form> tags in the HTML and change action="http://..." to action="https://...", or better yet to a relative path (action="/login") — that inherits the page’s protocol.
Step 2 — force HTTPS across the whole site
Even if you fix a specific form, a visitor can still reach it over http://. The server must redirect — see Site runs on HTTP only.
Step 3 — HSTS
Once HSTS is deployed, the browser stops establishing HTTP connections altogether — even if the user types http://example.com. For details, see Strict-Transport-Security.
Step 4 — subdomains
If the admin or legacy app lives on a subdomain, put a certificate on it too. A wildcard certificate from Let’s Encrypt (*.example.com) covers everything.
Verification
# in the browser open DevTools → Network → submit the form
# the request URL must start with https://