HTTPS Form Posts to HTTP: How to Fix the Insecure Form

What "HTTPS Form Posts to HTTP" means

This issue fires when one of your pages is loaded securely over HTTPS, but a form on that page submits its data to an insecure HTTP address. The page itself is encrypted, yet the moment the visitor clicks submit, whatever they typed (a name, an email, a password, a credit card number) travels to the server in plain text. The lock icon in the address bar promises safety the form does not actually deliver.

Browsers treat a form whose target is HTTP as "active mixed content." Active mixed content is content that can change the behavior of the page, and forms qualify because the destination receives and processes user input. According to MDN's documentation on mixed content, browsers sort insecure requests into upgradable and blockable categories, and active mixed content like an insecure form target is treated as a serious risk.

Why an insecure form action is dangerous

Data interception

When a form posts over HTTP, the submission is not encrypted in transit. Anyone positioned between the visitor and your server (on shared WiFi, a compromised router, or a hostile network hop) can read the data as it passes. Worse, because forms are active content, an attacker can do more than eavesdrop. As web.dev explains, an attacker can intercept and rewrite active content and use it to take full control of the page or even the entire site. That means injected fields, redirected submissions, and stolen credentials, not just passive snooping.

Browser warnings and blocking

Modern browsers actively defend against this. They either warn the user before the form is sent or block the insecure submission outright. Chrome, Firefox, and other browsers display a warning when a secure page tries to submit a form to an insecure endpoint, and increasingly they upgrade or block the request entirely. The result is a broken form, a scary security interstitial, or a silently dropped submission, none of which inspire trust or capture the lead you wanted.

Trust and SEO signals

Google has long encouraged HTTPS everywhere, and an insecure form undercuts the secure experience users expect. Visitors who see a "not secure" warning at the moment of conversion abandon. Search engines reward sites that deliver a consistent, secure experience, so leaving a form leaking to HTTP works against both your conversions and your technical-SEO health.

How to diagnose it

Find the offending form by viewing the page source and searching for action="http:// or action='http://'. The form's opening tag will reveal the insecure target. You can also open your browser developer tools, load the page, and check the Console and Security panels, which flag mixed content. A site crawl that inspects form action attributes (the kind SEO ProCheck runs) will surface every page where a secure document points a form at an HTTP URL, so you fix the pattern site-wide rather than one page at a time.

How to fix it

Point the form action at HTTPS

The direct fix is to change the form's action so it targets the HTTPS version of the same endpoint. If the endpoint lives on your own domain, a protocol-relative or root-relative path also works because it inherits the page's secure scheme.

<!-- Bad: secure page posting to an insecure endpoint -->
<form action="http://example.com/subscribe" method="post">

<!-- Good: explicit HTTPS target -->
<form action="https://example.com/subscribe" method="post">

<!-- Also good: root-relative path inherits the page scheme -->
<form action="/subscribe" method="post">

Enforce HTTPS site-wide

Fixing one action attribute is not enough if your server still answers on HTTP. Redirect all HTTP traffic to HTTPS at the server level and add the upgrade-insecure-requests Content Security Policy directive, which instructs the browser to treat insecure URLs as if they were secure before any request goes out. Per MDN's CSP guide, this directive is built for sites with many legacy insecure URLs that need rewriting. You can deliver it as a response header or as a meta tag.

<!-- Tell browsers to upgrade insecure requests automatically -->
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

# Apache .htaccess redirect to HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

You can also lock down where forms are allowed to submit with the CSP form-action directive, which restricts the URLs a form is permitted to target.

Common mistakes

Hardcoded http in the action attribute

The most frequent cause is a full absolute URL beginning with http:// baked into the template by a developer, a page builder, or an old theme. Because the scheme is hardcoded, it stays insecure even after the rest of the site moves to HTTPS. Search your theme, templates, and database for the literal string http:// inside action attributes and replace it.

Third-party endpoints that only offer HTTP

Sometimes the form posts to an external service (a mailing-list provider, a legacy CRM, a payment gateway) whose endpoint URL was set up years ago on HTTP. Check whether the provider now offers an HTTPS endpoint, which almost all reputable ones do, and swap to it. If a vendor genuinely cannot accept HTTPS, that is a signal to move to a provider that can, because no user data should leave a secure page over an unencrypted connection.

FAQ