Form Posts to HTTP: How to Fix Insecure Form Submissions

What this check flags

This check looks for forms living on a page served over HTTPS whose action attribute points to an http:// URL. The page itself is secure, the padlock shows, the visitor trusts it. But the form is the part that moves their data, and that part is set to travel in the clear. That mismatch is what we call a mixed form, and it is a flavor of mixed content.

The danger is invisible until the visitor hits submit. They fill in a name, an email, a password, maybe a card number, all while looking at a secure page. The leak happens the moment the form posts.

Why browsers warn and block on submit

Starting with Chrome 86, the browser stopped quietly hiding the padlock and started acting. Chrome now disables autofill on mixed forms, shows inline warning text when a visitor begins typing, and throws a full-page interstitial when they try to submit, blocking the post until the visitor explicitly chooses to send the data anyway. Firefox treats an insecure form action as mixed content too. The point of these warnings is that the old behavior, just removing the padlock, did not communicate the real risk to anyone.

For you that means a real conversion problem. A visitor who hits "your form is not secure, send anyway?" at submit almost always backs out. So this is both a security defect and a leak in your funnel.

The data-in-transit risk

Anything sent over HTTP can be read and changed by anyone sitting between the visitor and your server: a shared coffee-shop router, a compromised access point, an internet provider injecting content. This is the classic man-in-the-middle position, and on an HTTP form post they see every field in plain text. OWASP is blunt about this in its Top 10: private data such as credentials, session tokens, and card numbers must always be encrypted in transit, and login landing pages must be served over TLS. An HTTP form action breaks that rule even when the surrounding page does not.

One thing worth knowing: Chrome also shows this warning when the form posts to HTTPS but then redirects the visitor to an HTTP URL afterward. The hop back to HTTP is enough to trip it.

How to fix it

The fix is small; the testing is what matters. Point the action at the HTTPS version of your endpoint.

<!-- bad: HTTPS page, HTTP form action -->
<form action="http://seoprocheck.com/submit" method="post">

<!-- good: action stays on HTTPS -->
<form action="https://seoprocheck.com/submit" method="post">

If the endpoint genuinely supports TLS, confirm it answers on HTTPS first, then update the action. A protocol-relative or relative action is fine as long as the page is HTTPS, because the browser resolves it against the secure page. Then audit every form on the page, not just the one the crawler flagged. Search and replace pages are the usual culprit, so grep your templates for action="http:// across the whole site. As a backstop, add a Content-Security-Policy with upgrade-insecure-requests so the browser rewrites stray HTTP subresource and form URLs to HTTPS automatically.

How to diagnose it

Open the page and use View Source, then search the HTML for action="http://. That tells you the exact form. The browser console and the Security panel in DevTools will also call out a mixed form when you load or interact with the page. If you submit a test form and Chrome throws the "the information you are about to submit is not secure" interstitial, you have found it. Check the resolved action, not just what is in the template, since redirects and JavaScript can rewrite it at runtime.

# find every HTTP form action in your templates
grep -rn 'action="http://' ./ --include="*.html" --include="*.php"

Common mistakes

The most common trap is a relative action that you assume is safe but that resolves to HTTP because of a base tag or a server config that downgrades the protocol. Always check the resolved URL in the network panel, not the source. The next is an old hardcoded endpoint: a payment gateway, a newsletter handler, or a search action that was set to http:// years ago and never touched while the rest of the site moved to HTTPS. Third-party embed code is a repeat offender here, since vendors hand you snippets with stale URLs.

Another mistake is fixing the visible form and missing the hidden one. Login boxes in headers, search forms in footers, and newsletter signups in templates all ship sitewide, so one bad template can flag hundreds of pages at once. Fix the template, not the page.