Form action over HTTP: the insecure form submission warning

A form on an HTTPS page that posts to http:// sends the data in the clear and browsers interstitial it. squirrel checks action and formaction.

What an insecure form action is

A form’s action attribute is the URL the browser submits to. When that URL is http://, the field values travel unencrypted regardless of how the page itself was delivered. The padlock in the address bar describes the document, not the submission.

The worst version is an HTTPS page with an HTTP action, because the user has every visual signal that the page is safe. Chrome and Firefox warn on it and may block the submission. A relative action such as /subscribe resolves against the document base URL, which is the page URL unless a <base href> overrides it, so it is safe on an HTTPS page with no HTTP base. Only actions that carry their own scheme are checked. formaction on a submit button overrides the form’s action and needs the same treatment.

What squirrel checks

The rule runs on every crawled page and emits a single check named form-https. It collects every <form action> plus every formaction on a real submit control, meaning button[formaction] that is not type="button" or type="reset", input[type="submit"][formaction] and input[type="image"][formaction]:

Fail when the page is HTTPS and at least one of those actions resolves to http:. Message: 2 form(s) on this HTTPS page submit to HTTP, and each item is labelled HTTPS page submits to <url> in the clear. Severity error.
Warn when the page is not HTTPS and an action still resolves to http:. Message: 2 form(s) submit to HTTP.
Pass when at least one action or qualifying formaction was collected and none of them submit over HTTP. Message: All forms use secure submission.
Info when the page carries no action or formaction at all, even if it has <form> elements. Message: No forms detected.

Empty actions, fragment-only actions and the non-network schemes javascript:, mailto:, tel:, sms:, data:, blob: and about: are skipped. So are relative actions, because their scheme comes from the page and security/https already reports that. An action that fails to parse is still flagged when it literally begins with http://.

How to fix it

<form action="https://example.com/subscribe" method="post">

Change the scheme at the source, or drop the origin entirely and use a relative action, which is safe as long as the document base URL is HTTPS. Check formaction on any submit button that overrides the form, since it is easy to miss in a template.


Rule ID	`security/form-https`
Category	Security
Scope	Per-page
Severity	error
Weight	6/10

Enable / disable

Disable this rule

[rules]
disable = ["security/form-https"]

Disable all Security rules

[rules]
disable = ["security/*"]

Enable only this rule

[rules]
enable = ["security/form-https"]
disable = ["*"]

security/form-captcha: the same forms, checked for bot protection.
security/https: the page scheme that a relative action inherits.
security/mixed-content: subresources with the same downgrade problem.
a11y/form-labels: the accessibility pass over the same markup.

Security findings ship in every audit next to the SEO, performance and agent experience rules. See Website security scan with AI for how an agent works through a report.

References

Check your site

Run squirrel audit https://example.com and open the Security section of the report. Every insecure form action is listed by page with the form’s selector and a markup snippet. Local audits are free.

Install squirrel

One command to install, one to run your first audit.

See a sample report

What the Security section looks like on a real site.

Edit this page