Fix guide · high · password_form_action_http

Password form submits over plain HTTP

What this rule means

A <form> containing an <input type="password"> submits to an http:// action — or the page itself is on http:// with no explicit action. The password ships in cleartext on every hop between the user and the destination server.

Why it matters

Every node on the path between your user and the form's destination — coffee-shop wifi, ISP, transit network, employer proxy, anyone who can ARP-spoof the local LAN — can read the password verbatim. TLS is the mitigation; if the form action is http://, TLS doesn't apply.

Browsers warn about this case (Chrome shows "Not secure" in the address bar when typing into a password field on an http page) but they don't block the submit. Users who've already started typing usually finish.

Two ways this shows up:

  1. Mixed content — page is https, but <form action="http://other.example.com/login">. The page loads securely but the submit goes cleartext. Often a hardcoded URL left over from a dev setup.
  2. Plain HTTP page — the page itself is http and the form has no action, so it submits back to itself, in cleartext. Almost always an accidental routing or deploy issue where the http variant of a site is still serving content.

How to fix it

  1. Change action="http://..." to action="https://..." everywhere. Audit every form on the site, not just login.
  2. Redirect HTTP → HTTPS at the edge. Every request to http://your-site.com should 301 to https://, before any HTML reaches the browser. Cloudflare's "Always Use HTTPS" rule handles this.
  3. Add HSTS so browsers remember the https-only requirement and refuse to ever load http again:

``http Strict-Transport-Security: max-age=63072000; includeSubDomains; preload ``

  1. Audit existing user sessions for the period the form was http. Any password submitted via an http form should be treated as potentially compromised; consider force-rotating sessions and notifying affected users.
  2. Block mixed-content forms via CSP: form-action 'self' https: refuses any http form-action.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.

Run another inspection