A form action uses http:// or sensitive fields sit on HTTP

Why it matters

The Chromium team describes forms on HTTPS pages that do not submit over HTTPS as a risk to users' security and privacy: information sent through them can be visible to eavesdroppers, who can read or change it. Chrome warns people who try to complete such forms.

What to do

Look at the finding: it shows the form tags and their action, or the sensitive fields; nothing anyone typed is recorded.
Change the form's action to an https:// address, or to a relative address that resolves over HTTPS under the document base.
Serve every page with a password or payment field over HTTPS only.

What we read

We read the HTML of each crawled page without running JavaScript and without submitting anything. On an HTTPS page, a form is reported when its declared action is a valid absolute http:// address or resolves to one through the captured document base and it has at least one enabled select or textarea, or an enabled input other than hidden, button, submit, reset or image. A readonly input can count; forms with method=dialog are excluded.

On a page served over HTTP, any password field, or any field marked with a payment card autocomplete value such as cc-number, is reported, inside a form or not. Pages that did not answer 200 with complete HTML cannot be checked. For HTTPS form declarations, a form or control inside a table, or a form nested inside another form, can prevent a conclusive result.

Example & evidence

Illustrative example — one form, not a live audit.

https://bakery.example/contact/ contains:

<form method="post" action="http://bakery.example/send">
  <input name="email" type="email">
  <button>Send</button>
</form>

The page is served over HTTPS, but the form declares an http:// submission address, so the page is reported with the form.

<form method="post" action="https://bakery.example/send">

A possible correction: send the form over HTTPS.

Confirm & check again

Check for yourself: view the page source and search for action="http:; on a page served over http://, search for type="password". Also inspect the document’s <base> address when the form action is relative.

Check again: Full audit — run a new audit of the site. The finding closes when the page is crawled again with complete HTML and none of its eligible forms declares an action that resolves to http://, or, for a page served over HTTP, it no longer has password or card fields. A page that is not crawled again, or whose forms can no longer be read, keeps the finding open.

Limits & sources

The check reads static form declarations and resolves actions against the captured page and document base. It does not submit forms or see where JavaScript sends data or a button-level formaction. Forms inside a body <noscript> are not visible to the scripting-enabled parse.

Confidence: High because the form and its fields are read directly from the HTML.

Sources

Chromium Blog, Protecting Google Chrome users from insecure forms — calls forms on HTTPS sites that do not submit on HTTPS a risk to users' security and privacy, because eavesdroppers can read or change what is sent. Checked 28 September 2026.

Editorial review: 2 November 2026

A secure page references active content at http:// addresses — the page references scripts or styles at http:// addresses.
Links and lists still point to http:// addresses — links and lists on the site still point to http:// addresses.

A form declares HTTP submission or sensitive fields appear on HTTP