Fix today

A form on your site sends data to another website

What it means

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

Most forms send to your own site. We found one that sends to a different website. That is common and often deliberate: a newsletter sign-up goes to your email marketing service, a "Buy now" button goes to your payment provider, a search box may go to a search engine.

It can also be a sign of tampering. Someone who breaks into a site can change where a form sends its data, or add a fake form, so that logins or card details go straight to them.

Why it matters

If the destination is a service you use, this is normal. Check it once, acknowledge it, and move on.

If you do not recognize it, visitors may be handing their details to a stranger while your site looks perfectly normal. Card and password theft often goes unnoticed for months, and the first sign can be customers reporting fraud.

Pay closest attention when the form asks for a password or payment details. Those should only ever go to your own site, or to a login or payment provider you set up yourself.

How to check your own site

1. Find the destination address in the alert, or open the page, right-click inside the form, choose Inspect, and look for the action= address on the line starting with <form.
2. Ask yourself: can I name the service behind this address, and did we set it up? Look at the main part of the domain, just before .com or similar, not the start of the address.
3. Compare it with the service's real domain. For example, Mailchimp sign-up forms send to an address ending in list-manage.com, PayPal buttons send to paypal.com, and HubSpot forms usually send to hsforms.com or hubspot.com. If you are unsure, copy fresh embed code from your account with that service and compare.
4. Warning signs: a name you do not recognize, a misspelling of a known brand or of your own domain, a bare number address like 203.0.113.44, a login or card form that sends to anyone other than your provider, or a destination that changed without anyone editing the form.

How to fix it

Any website

1. If you recognize the destination as a service you use, acknowledge it in your EverThread dashboard and we will stay quiet about it.
2. If it is another part of your own business, such as shop.yoursite.com or a booking system you pay for, that is also fine to acknowledge.
3. If you do not recognize it, act today. Take a screenshot of the form and note the destination address, then remove or hide the form so no one else fills it in.
4. Ask your developer to find how it got there: recently changed files, new plugins or apps, new admin accounts, and any other unfamiliar code on the site. Change the passwords for your site, hosting and domain accounts.
5. If the form collected card details or passwords, contact your payment provider and let affected customers know they should change their passwords. Depending on where you operate, you may have legal duties to report a breach.

WordPress

1. Check the form plugin's settings for that form, and any Custom HTML blocks or widgets on the page, to see where the destination is set.
2. If you did not set it, look under Plugins for anything you do not recognize, and under Users for administrators you did not add.
3. Unfamiliar code in theme files or a changed form usually means the site was broken into, often through an outdated plugin or a reused password. Your developer or host should clean it up, update everything and change all passwords.

Shopify, Squarespace, Wix and other hosted builders

1. Built-in forms and checkout send to the platform itself. A form sending elsewhere almost always comes from an app, an embed or a code block someone added.
2. Check your installed apps and any code blocks or code injection settings on that page. Remove anything you do not recognize, and review who has staff or contributor access.
3. Turn on two-step login for every account, and contact the platform's support if you think your account was used by someone else.

Apache or Nginx

1. Once you have confirmed which outside services are legitimate, your developer can add a Content-Security-Policy form-action rule. Browsers then refuse to send forms anywhere not on that list, so a tampered form fails instead of leaking data.
2. List your own site and each service you use, test on a staging copy first, then add it to the server or hosting headers.

Content-Security-Policy: form-action 'self' https://*.list-manage.com https://www.paypal.com

What to send your developer

A form's resolved action targets a host outside the site's allowlist. Confirm it matches a vendor the business uses, by comparing with the vendor's current embed code. If it is unexplained, preserve evidence first, then diff templates and database content against a known-good copy, review recently modified files, plugins and admin accounts, and rotate credentials. Also check for scripts that rewrite form.action or read field values at runtime. A CSP form-action allowlist limits future tampering.

Content-Security-Policy: form-action 'self' https://trusted-vendor.example

Common questions