Insecure Form Scanner

How this check works

Scanaris parses the HTML of your main page and looks for forms that contain an <input type="password"> field: a login, a sign-up, a password change. If there is none, it does nothing. If there is, it checks two things. First: if the page itself was served over HTTP, it opens a high-severity finding, because everything the user types travels unencrypted. Second: if the page is HTTPS but the form's action attribute starts with http://, it opens another high-severity finding with that URL, because the actual submission of the password leaves unencrypted even though the page asking for it was secure. Only the scanned page is examined; if your login lives on another route, scan it directly.

Why it matters

A password is the most valuable thing a user hands you, and it is the one unencrypted connections treat worst. When a form travels over HTTP, anyone along the way (the wifi in a café, the access provider, a compromised router) can read the username and password as is, with no technique at all. And since most people reuse passwords, what leaks is not just access to your site. Browsers know this: Chrome and Firefox mark any password field on an HTTP page in red and warn the user that it is "not secure", so on top of a real risk it is a visible loss of trust.

Why it happens

The first case shows up when the site does not redirect HTTP to HTTPS and someone arrives through an old link. The second is almost always an action typed by hand during development (http://localhost:3000/login or http://api.mydomain.com/auth) that nobody changed, or a form copied from an example. It also happens when the login points at an external service that does not have a certificate yet.

How to fix it

• Serve the whole site over HTTPS and redirect HTTP. It is the foundation for everything else; the HTTPS redirect check tells you whether you have it. On Vercel, Netlify or Cloudflare it comes done; on your own server, a redirect block in nginx or Apache.
• Change the action to a relative path (action="/login"), which inherits the page's protocol, or to the full URL with https://. If you use a framework (Nuxt, Next.js, Laravel, Django), the API URL should come from an environment variable with the production value, not be written in the template.
• If a third party handles the login (Auth0, Supabase, Firebase, Clerk), their endpoint is already HTTPS; the finding then points at an action of your own that should not be there.
• Add HSTS so the browser never tries HTTP again, not even on the first hop; weak HSTS measures it.

Check it is fixed

curl -sI http://yourdomain.com/login | grep -iE "^(HTTP|location)"
curl -s https://yourdomain.com/login | grep -oE '<form[^>]*action="[^"]*"' 

The first must return a 301 to https://. In the second, no action may start with http://; normally you see relative paths or nothing (forms without action submit to the page itself).

Frequently asked questions

My form submits through JavaScript, not through action. Does this affect me?

This check looks at the action attribute, so a form that calls fetch is not flagged that way. But the risk is the same if the fetch points at http://: on an HTTPS page the browser will block it as mixed content, and on an HTTP page it travels in the clear. Review the API URL all the same.

It is only a staging environment with no real users.

Then do not scan it as if it were production, or accept the finding. But watch out for staging environments that end up in Google: if someone creates an account there with their usual password, the problem is real.

Is a password field on an HTTPS page with a relative action fine?

Yes. That is the correct setup and produces no finding. What remains is how you store the session afterwards: insecure cookies and token in storage cover that part.