Form submitting over HTTP

HTTPS protects the transfer of the page from the server to the browser.

The form action is a separate request, made when the visitor submits, to whatever URL the attribute names.

If that URL uses HTTP, the submission travels unencrypted and readable by anyone on the path.

The address bar indicator describes the page, so a visitor has no signal until the browser intervenes at submission.

Which means the defect is invisible during normal use and only surfaces at the worst moment.

A hard-coded absolute URL written when the site was HTTP, left in a template that survived the migration.

A form posting to a third party — a mailing list provider, a payment gateway, a search service — whose documented endpoint was HTTP and was never updated.

A configuration value holding a base URL with the wrong scheme, used to build the action.

A search form whose action was copied from an example.

In each case the form works, which is why nothing draws attention to it.

They show a warning at submission, and some replace the submit control's behaviour with a confirmation.

The wording is deliberately alarming, which is appropriate and costs you the submission.

Some browsers block the submission entirely depending on configuration and on what is being sent.

Which means this is a conversion problem as well as a security one: the visitor reaches the final step and is told the site is unsafe.

An HTTP action on a password or payment field triggers the strongest treatment.

Change the action to the HTTPS URL, which for your own endpoints is immediate.

For a third-party endpoint, check their current documentation — nearly all of them publish an HTTPS endpoint now, and the HTTP one may only exist for compatibility.

Prefer a relative action where the form posts to the same site, which inherits the page's scheme and cannot drift.

Do not rely on the endpoint redirecting to HTTPS: the redirect happens after the insecure request has already crossed the network with the data in it.

Check every form, including search boxes and newsletter signups, since those are the ones nobody reviews.

Scripts and stylesheets loaded over HTTP from an HTTPS page, which browsers block outright as mixed content.

Images and media over HTTP, which browsers upgrade or block depending on the case.

A form action is treated differently from both: it is not blocked by default because blocking it would break submission silently.

Which is why it needs finding deliberately rather than appearing as a console error.

Search the served HTML for form elements and read the action attribute on each.

Any action beginning with the HTTP scheme is the defect, including one pointing at your own domain.

An empty or relative action inherits the page's scheme and is safe by construction.

Check third-party forms embedded in your pages, which are the ones you did not write and did not review.

Submit a test form and watch the network panel for the request scheme, which is the authoritative answer.

`structure.html_quality` reports the defect in the stored markup sample and emits the issue code for an insecure form action.

`transport.mixed_content` reports insecure references from HTTPS pages generally, which is the neighbouring category.

`transport.https` and `transport.http_redirect` establish whether the site itself is served securely, which frames the finding.

`cookies.secure` is reported alongside, since a form posting over HTTP also sends any cookie lacking the Secure attribute.

A form using GET puts every field value in the URL, which lands in browser history, server logs and referrer headers — insecure in a different sense even over HTTPS.

Anything collecting a credential or a payment detail belongs in a POST regardless of the scheme.

An autocomplete attribute set to off on address or payment fields costs typing and errors without adding security, which is a related instinct producing a related cost.

A form posting to a third party sends the visitor's data to that company directly, which is a processing question as well as a transport one.

Each of these is visible in the same markup as the action attribute, so reviewing forms once covers all of them.