Login forms that leak passwords: HTTP and cross-origin posts

Everyone remembers to add HTTPS to the address bar. Fewer people check where the login form actually posts. A page can load over HTTPS and still submit its password field over plain HTTP, or to a different origin entirely — and the padlock icon will not warn you. The credentials go out in the clear regardless.

This happens in vibe-coded apps because the form action and the page URL are set in different places, by a model that does not reason about the security boundary between them. The result is a login form that looks fine and leaks every password typed into it.

The two shapes of the bug

• HTTP submission: the form's action is an http:// URL (or a relative action on a page reachable over HTTP). Anyone on the same network — coffee-shop Wi-Fi, a compromised router — reads the password in transit.
• Cross-origin submission: the form posts to a third-party domain. Even over HTTPS, you are now trusting that domain with raw credentials, and a typo or a stale endpoint can send them somewhere you do not control.

How to check

View the login form's HTML and read the <form action> and the action on any password <input>. Confirm the action is https:// and points at your own origin. Load the site over http:// and confirm it redirects to HTTPS rather than rendering a working form. Open the network tab, submit test credentials, and verify the request goes where you expect over TLS.

The fix

• Serve every page with a credential field over HTTPS only, and redirect HTTP to HTTPS (HSTS makes this sticky).
• Point form actions at your own origin; never post passwords to a third-party domain.
• Add autocomplete attributes correctly and avoid logging form bodies anywhere server-side.

VibeSafely's insecure-credential-form check flags password forms that submit over HTTP or to an unexpected origin, so you catch a leak that the browser's padlock will happily hide.