Fix today

A form on your site sends what people type insecurely

What it means

Every form has a destination: the address its contents are sent to when someone presses Submit. In the page's code this is the form's action.

Your page loads securely over https, but we found a form whose destination starts with http://. When a visitor submits it, their name, email, message or password leaves the secure page and travels in readable text.

The destination is often your own site, written with an old http:// address from before the site moved to https. Sometimes it is an older form or mailing list service.

Why it matters

Anything sent over plain http can be read or changed by someone between the visitor and the destination, such as on shared Wi-Fi. If the form includes a password, this is urgent.

Browsers notice too. Chrome warns people before they send a secure page's form to an http address, and it turns off autofill on that form. Many visitors stop right there, so you may be losing inquiries without knowing it.

A redirect from http to https does not fix this. The browser sends the form data over http first and only then gets told to use https, and some redirects drop the data entirely.

How to check your own site

1. Open the page in Chrome, Edge or Firefox. Right-click inside the form and choose Inspect.
2. In the code panel, look a few lines up for a line starting with <form. The address after action= is where the form sends its data. If it starts with http://, this is the form we flagged.
3. Check every page with a form: contact, quote request, newsletter sign-up, login and checkout.

How to fix it

Any website

1. Note the form's destination address from the check above.
2. If it is your own domain, change http:// to https://. Better still, use an address without the domain at all, such as /contact, so it always follows the page.
3. If it belongs to a form or mailing list service, open that address with https:// in front. If it works, update the form. If not, get fresh embed code from the service, which should be https, or switch to a service that supports it.
4. Submit a test entry afterward and make sure it arrives.

WordPress

1. Under Settings, General, make sure "WordPress Address" and "Site Address" both start with https://. Many themes and plugins build form addresses from these settings, so an old http:// value here is a common cause.
2. Open the form plugin's settings for the affected form and look for a custom action, redirect or submission address that starts with http://.
3. If the form was pasted in as HTML, in a Custom HTML block or a widget, edit it and change the action address.
4. Clear any caching plugin afterward, so visitors get the corrected page.

Shopify, Squarespace, Wix and other hosted builders

1. The platform's own forms send over https. An http destination almost always comes from something you pasted in: a code block, an embed, or HTML from a mailing list or booking service.
2. Find that code block on the page, change the action address to https, and save. If the service does not support https, replace the embed with the platform's built-in form or a current embed from the service.

Cloudflare

1. Cloudflare settings like "Always Use HTTPS" redirect visitors to https, but they cannot fix a form that already points to http. The data leaves the browser before the redirect happens.
2. Fix the form's address in your site itself, using the steps above.

Apache or Nginx

1. Server settings cannot rewrite where a form sends its data. Search your templates and site content for action="http:// and change each one.
2. Once that is fixed, a Content-Security-Policy with form-action tells browsers to refuse insecure form destinations, as shown below. Test it on a staging copy first, and list any outside form services you use.

Content-Security-Policy: form-action 'self' https:

What to send your developer

An HTTPS page contains a <form> whose resolved action uses http://. Change it to https or a relative URL. Check templates, CMS settings that generate absolute URLs, and third-party embed code. Do not rely on an http-to-https redirect: the request body is already sent in cleartext, and 301 or 302 responses to a POST are often replayed as GET, dropping the data. A form-action directive in Content-Security-Policy will block regressions.

grep -rn 'action="http://' .

Common questions