Form submits over HTTP

Scan.now parses every <form> on the HTTPS homepage and resolves its action attribute against the page URL, along with any formaction attribute on submit buttons inside it. A form whose resolved target begins with http:// fails the check at high severity. Forms with no action submit to the page's own URL and pass. The report lists the form's target, its method, and whether it contains type="password", type="email" or card-number-looking fields, which raises the priority. If port 80 serves page content instead of redirecting, Scan.now also reports any password field found on that HTTP page, since credentials typed there are unprotected regardless of where the form posts. Nothing is submitted; the markup alone is examined. Other HTTP resource references are handled by mixed-content.

A visitor sees a padlock and a login box and reasonably assumes the password will be encrypted. If the form posts to http://, the credentials travel in the clear on the very next request, where any on-path observer, from a Wi-Fi hotspot to a compromised router, reads them. Attackers also deliberately engineer this pattern on phishing pages because the visible page looks secure. Browsers have caught up: since Chrome 86 a mixed form submission shows a full-page "The information you're about to submit is not secure" warning, and Firefox shows a warning on password fields of insecure pages, so the immediate effect is lost sign-ups and lost trust even before any interception. On a plain-HTTP page, the same applies with no warning at all in older browsers. The mixed content guide and the HTTPS-only mode guide explain what users see.

Point the form at an HTTPS or relative URL:

<form method="post" action="/login">

Absolute http:// actions are usually generated by a framework that does not know it is behind a TLS-terminating proxy. Fix the proxy headers and the framework's trust setting rather than hard-coding URLs. nginx:

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;

Django: SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https'). Express: app.set('trust proxy', 1). Rails: config.force_ssl = true. Then add a CSP directive that makes the browser refuse any insecure submission, so a regression is blocked instead of shipped:

Content-Security-Policy: form-action 'self' https:; upgrade-insecure-requests

Apache: Header always set Content-Security-Policy "form-action 'self' https:". Finally, make sure port 80 redirects to HTTPS (see http-redirects-to-https), so no page containing a password field is ever served unencrypted.