Mixed-Content Form Action Blocked (HTTPS→HTTP)

What’s actually happening

The page loads over HTTPS, but the <form action> points to an http:// URL. Chrome shows a 'The information you're about to submit is not secure' interstitial on submit; newer versions can block the POST outright. The DevTools console logs a 'Mixed Content' warning, and users either bounce at the scary warning or their submission never reaches your handler.

Common causes

• A hard-coded action="http://..." left over from before the site moved to HTTPS
• The form endpoint only upgrades to HTTPS via a redirect after the insecure POST — the initial action is still http://
• An absolute action URL built from a site setting/env var that still stores the http:// base URL
• A third-party form handler or CRM endpoint referenced over http://
• CMS or theme template generating the action attribute from a non-HTTPS home_url (common after an incomplete WordPress HTTPS migration)

How to fix it

1. Point the action attribute directly at the HTTPS URLChange action="http://example.com/submit" to action="https://example.com/submit", or use a protocol-relative/relative form (action="/submit"). The browser only blocks the cross-protocol downgrade — a same-protocol HTTPS action submits cleanly.
2. Find every offending formOpen DevTools → Console on each form page and look for 'Mixed Content' submission warnings, or crawl with a tool that reports insecure form actions. Grep the templates/theme for action="http: to catch hard-coded ones in bulk.
3. Fix the source of the URL, not just one templateIf the action comes from a stored base URL (WordPress Settings → General, or an env/config var), update it to https:// so every generated form is corrected at once. For WordPress, also run a search-replace of http://yourdomain → https://yourdomain across the database.
4. Don't rely on the endpoint's own redirectA handler that 301s http→https doesn't help here — the browser blocks or warns before the POST is sent, and even if sent, redirecting a POST can drop the body. The action itself must be https:// from the start.
5. Add a backstop with upgrade-insecure-requestsSet the Content-Security-Policy: upgrade-insecure-requests header (or meta tag) so any remaining http subresource/action references get auto-upgraded to https. Treat this as a safety net, not the primary fix.