WordPress contact forms: a security checklist

Most WordPress sites use one of a handful of form plugins: Contact Form 7, WPForms, Gravity Forms, Ninja Forms, Fluent Forms and a few others. Any of them can be run securely or left wide open. The difference rarely lies in the plugin itself, but in its settings, the add-ons around it, how mail leaves the server and what happens to messages once they arrive.

• Keep the form plugin and every add-on up to date, and delete the ones you no longer use.
• Enable the plugin’s own anti-spam – honeypot, CAPTCHA integration, Akismet where it fits – and confirm it actually works.
• Send notifications through authenticated SMTP from an address on your own domain.
• Restrict uploads by type and size, and keep uploaded files from being publicly listed or browsed.
• Keep the recipient e-mail address out of the page and its source code.
• Store only the entries you need, and only for as long as you need them.
• Run a short check after every update to WordPress, the theme or any plugin.

Updates: the form plugin and everything around it

Form plugins are popular targets because they accept input from anyone on the internet. Security fixes arrive as ordinary updates, so update promptly – and not only the main plugin. Add-ons for payments, uploads, CRM connections, conditional logic or extra CAPTCHA providers are separate code with their own vulnerabilities. So are plugins you once installed for a test and forgot. Deactivating is not enough: deactivated plugins still sit on the server, and their files can in some cases be reached directly. If you don’t use it, delete it.

Anti-spam: switch it on, then prove it works

Most form plugins have their own anti-spam options or integrate with external services: a honeypot field that bots fill in and humans never see, CAPTCHAs such as reCAPTCHA, hCaptcha or Cloudflare Turnstile, and Akismet, which checks message content against a spam database. Options vary by plugin and version, so check the settings rather than assuming. External CAPTCHAs load scripts from a third party, and Akismet sends the submitted content to an external service – both belong in your privacy policy and, depending on your setup, in your consent management.

The more common problem is protection that is switched on but doesn’t work. A CAPTCHA running on public test keys lets everything through. A widget whose script is blocked by a caching or optimisation plugin, or by a JavaScript error, stops nothing. A honeypot field without the styles that hide it is read out by screen readers and filled in by real visitors. So after any change, open the form in a private window, check the browser console and page source, and send a test message. If you want protection that doesn’t depend on Google, the free formexposed WordPress plugin adds a honeypot, a time check and proof-of-work and re-checks the site after plugin updates – one option among several.

Mail: how it is sent and where it goes

By default, WordPress hands mail to the server’s PHP mail function, and on many hosts those messages are poorly authenticated and end up in spam – or silently disappear. Instead, send through an SMTP plugin or your host’s mail service, using a real mailbox with a username and password and a sender address on your own domain, such as a dedicated forms@ address. The domain’s SPF, DKIM and DMARC records must cover this sender. Don’t put the visitor’s address in the From field: it isn’t your domain, so the message cannot pass DMARC alignment and, depending on the visitor’s domain policy, lands in spam or is rejected. Set it as Reply-To, and you can still answer with one click.

The recipient address belongs in the plugin settings, not in the page. Check your contact page’s source: a mailto link next to the form, or a hidden field holding the recipient address, hands that address to every harvesting bot. In older or custom-built forms it can be worse – if the server trusts a hidden recipient field, anyone can change it and use your form to send mail to arbitrary addresses.

Uploads and stored entries

File uploads are the riskiest form feature, so first ask whether you need them at all. If you do, allow only the types you actually expect – say PDF and common image formats – instead of blocking a few dangerous ones, and set a size limit. Check where the plugin stores uploads: they must not be listable in a public directory and ideally not reachable at a guessable address at all. Delete them once they have been dealt with, or send them as attachments instead of keeping them on the server.

Many form plugins or their add-ons save each submission in the WordPress database, often including spam. That is a useful backup when mail fails, but also a growing pile of personal data. Under the GDPR principle of storage limitation (Art. 5(1)(e)), such data should be kept no longer than necessary. Decide whether you need stored entries, which fields and for how long, then use the plugin’s auto-delete setting if there is one, or delete old entries regularly. Database backups contain the same data.

After every update

1. 1Open the contact page in a private window: the form and its anti-spam element display correctly, and the browser console shows no errors.
2. 2View the page source: the honeypot field and the CAPTCHA script are still there, and the recipient address is not.
3. 3Send a test message: it lands in the inbox, not in spam, and the headers show SPF, DKIM and DMARC passing.
4. 4Check the settings that matter: recipient, sender address, allowed upload types and sizes, how long entries are kept.
5. 5Check that the privacy policy link and any consent text are still shown at the form.
6. 6Note the date and what you checked, so you know when the form last provably worked.

Once it is routine, this takes little time and catches exactly the quiet failures that otherwise go unnoticed for weeks. For an outside view, a free check on formexposed.com looks at a site’s public form pages without submitting anything and shows whether the protection you expect is in place and configured effectively – no account needed.