WordPress Form Security Checklist: 14 Things to Check Right Now

A form is the one part of your WordPress site that’s built to accept input from total strangers. That’s what makes it useful, and it’s also what makes it worth locking down. Whether it’s a contact form, a payment form, or a job application, every time someone submits it, you’re letting a stranger send data straight into your site.

This checklist works no matter which form plugin you use. It’s organized by attack surface, not by settings menu, so you can run through it against your own site and know exactly what to check and why. When we mention FormGent, we checked FormGent’s actual code. We didn’t just trust what the settings screen says. That turned up a couple of spots where a protection runs only in the visitor’s browser, not on the server. That might sound like a small detail, but it’s the difference between a check a bot has to pass and one it can simply skip.

Want the bigger picture first? WordPress Form Security: The Complete Guide (2026) covers why forms get targeted at all, how these individual checks fit together as layers, and how to judge how much protection a given form actually needs. This checklist is the hands-on companion to that guide, so read either one first, they point to each other.

Quick-Reference: The 14-Point Checklist

1. Get your site on HTTPS, not just the form
2. Keep WordPress core, your form plugin, and your theme updated
3. Lock down admin logins with strong passwords, attempt limits, and 2FA
4. Choose secure, reputable hosting
5. Enable a honeypot field
6. Add a token-based or hidden-field spam check
7. Use CAPTCHA, hCaptcha, or Cloudflare Turnstile, and know the trade-offs
8. Consider a third-party spam filter for high-traffic forms
9. Require double opt-in for forms that collect email addresses
10. Understand validation vs. sanitization, and never trust the client-side check alone
11. Secure your file upload fields by MIME type, not just extension
12. Limit file size and count, and keep uploads out of direct execution paths
13. Control who can view, export, and delete form entries
14. Handle GDPR and data-privacy basics properly

If you only do five things off this list, do 1, 2, 5 or 6, 10, and 13. Everything else scales with how much traffic and risk your form actually carries.

Part 1: Lock Down the Site Your Form Lives On

1. Get your site on HTTPS (SSL/TLS), not just the form

Any form submitted over plain HTTP sends its data in plain text. Names, emails, phone numbers, whatever you’re collecting — anyone sitting between the visitor’s browser and your server can read it. An SSL/TLS certificate stops that. It encrypts the connection, and it’s what turns your address bar from http:// into https://.

This isn’t optional anymore. Since 2018, browsers have marked HTTP pages “Not Secure.” That warning pops up right when someone’s about to submit your form — the exact moment you don’t want them having second thoughts about your site. Most hosts now give you a free SSL certificate automatically, so there’s rarely a good reason to skip it.

Getting SSL right is your host’s job, or yours, not your form plugin’s. FormGent doesn’t control this, and neither does any other form plugin. Check it now, and check it again any time you move hosts or change your domain. A messy migration is the most common way a site quietly ends up without a certificate.

2. Keep WordPress core, your form plugin, and your theme updated

Most exploited plugin vulnerabilities already had a fix available. The damage happens in the gap between the fix coming out and you actually installing it.

Two habits close that gap:

• Turn on auto-updates for minor WordPress releases and for plugins you trust. Prefer to review changelogs first? Set a fixed weekly time to check for updates instead.
• Before you update a form plugin, or right after if something breaks, look it up on a vulnerability tracker like Patchstack or WPScan. They list disclosed vulnerabilities by plugin and version, so you can check in a few seconds whether your version has a known issue.

Also worth doing: remove plugins you’re not using anymore. A deactivated plugin sitting in your files can still be a target if you never actually delete it.

3. Lock down admin logins with strong passwords, attempt limits, and 2FA

This isn’t specific to forms, but it belongs on this list anyway. Once an attacker gets into an admin account, they can see every form entry your site has ever collected, and they can change your form settings however they want.

• Use long, random passwords for every admin and editor account. A password manager makes this easy.
• Limit login attempts. After a handful of failed tries, lock the account out for a while so brute-force scripts can’t just keep guessing.
• Enable two-factor authentication (2FA) on any account that can access the WordPress dashboard. Even a cracked password is useless to an attacker without the second factor.

4. Choose secure, reputable hosting

Shared hosting puts your site on the same server as dozens, sometimes hundreds, of other sites. If one of them gets hacked or starts sending spam, you can get dragged into the mess too. Your shared IP address might get flagged. Your shared email server might get blocked. And if the host doesn’t wall off accounts from each other properly, a security hole in someone else’s site can even become a problem for yours.

VPS hosting, managed WordPress hosting, and dedicated hosting all give you better isolation from other sites. They also usually come with a firewall that blocks a lot of bad traffic before it even reaches WordPress. That helps your forms too. Most spam bots that hit forms look just like the other bot traffic your host is already blocking.

Part 2: Stop Spam and Bots Before They Submit

5. Enable a honeypot field

A honeypot is a form field that’s invisible to a real visitor but visible to a bot reading the page’s raw HTML. Most spam bots don’t render a page the way a browser does — they scan the markup and fill in every field they can find, including ones hidden with CSS. A real person never sees the field, so they never fill it in. A submission that arrives with that field filled in is almost certainly a bot.

Test it yourself: open your browser’s developer tools, disable JavaScript for the page, and try submitting your form. If your honeypot only runs in the browser’s JavaScript, turning JavaScript off skips the check entirely. The form will act like the honeypot was never there, because the code that checks it never gets a chance to run. If your plugin enforces the check on the server instead, the submission should still get rejected even with JavaScript off. This single test tells you more about how your spam protection actually works than any settings screen will.

FormGent note: FormGent adds a hidden honeypot field to every form automatically, on by default, with zero setup on your end. It works exactly the way a honeypot should: real visitors never see the field, and a submission that comes back with it filled in gets blocked before it goes anywhere. We checked the actual mechanics, and this check runs in the visitor’s browser rather than on the server, which means it catches the large majority of basic bots, the kind that blindly fill in every field they find, but won’t stop a bot built to skip JavaScript entirely and post straight to the submission endpoint. That’s worth knowing, not a reason to turn it off — pair it with a second layer (point 7) once a form starts attracting more determined spam.

6. Add a token-based or hidden-field spam check

There’s a second, lesser-known layer that works differently from a honeypot. When a visitor loads your form, your server creates a unique token and puts it in a hidden field. When they submit, the browser sends that token back along with their answers. If the token is missing, doesn’t match, or was already used, the server rejects the submission — no visitor interaction required.

This layer works differently from a honeypot. A honeypot depends on the bot making a mistake, like filling in a field it shouldn’t. A token check doesn’t wait for a mistake. To get a valid token, the bot has to actually load and read your page first, and that’s much harder to fake.

FormGent note: you don’t have to turn this on. It’s just how FormGent works. When your form loads, FormGent gives it a token. When someone submits the form, FormGent checks that token before it accepts anything they typed. No token, no match, no submission. This runs on every form, no matter what other spam settings you’ve turned on.

7. Use CAPTCHA, hCaptcha, or Cloudflare Turnstile, and know the trade-offs

CAPTCHA makes a visitor prove they’re human before your form lets them submit. The common options aren’t all the same, though. Pick the wrong one for your traffic, and you could lose more real visitors than the spam you block.

	Visitor sees anything?	Data sent to third party	Accessibility	Typical use case
Google reCAPTCHA v2	Yes — checkbox, sometimes a puzzle	Yes, to Google	Can be difficult for screen-reader or low-vision users	Organizations already standardized on Google’s tools
hCaptcha	Yes — checkbox, sometimes a puzzle	Yes, to hCaptcha	Same accessibility concerns as reCAPTCHA v2	Teams that want CAPTCHA without a Google dependency
Cloudflare Turnstile	Usually no	Yes, to Cloudflare	Usually the most accessible option, since there’s often nothing to see or interact with	Sites that want the lowest possible friction

One thing people miss: puzzle-style CAPTCHA is hard on some visitors. If someone uses a screen reader or has low vision, an image puzzle can shut them out completely. A checkbox doesn’t have this problem. That doesn’t mean skip CAPTCHA. Pick an option that has a fallback for a visitor who genuinely can’t finish the challenge. And if friction and accessibility both matter to you, lean toward an invisible option like Turnstile.

FormGent note: FormGent’s Captcha field offers three providers: Google reCAPTCHA, hCaptcha, and Cloudflare Turnstile. The reCAPTCHA here is the v2 checkbox style, not the invisible v3 version. All three get checked on FormGent’s server, not just in your visitor’s browser. Every time someone submits, FormGent sends their token to the provider (Google, hCaptcha, or Cloudflare) and waits for confirmation before accepting the form. Why this matters: Cloudflare itself says showing the Turnstile box isn’t enough. A site can display the widget and still be unprotected if it never checks the token with Cloudflare. FormGent does that check for you automatically. For full setup steps, read Honeypot vs CAPTCHA vs Turnstile.

8. Consider a third-party spam filter for high-traffic forms

Services like Akismet check every submission against a huge database of known spam. They look for patterns, not just one hidden field or one challenge.

For a low-traffic contact form, a honeypot plus CAPTCHA is usually enough. But some forms see much more traffic. An open registration page. A public directory listing form. Anything getting hundreds of entries a day. For those, a dedicated filtering service catches things a honeypot and CAPTCHA miss. One example: a real person typing out a scripted sales pitch by hand. CAPTCHA and honeypot can’t catch that. Neither one looks at what the message actually says.

9. Require double opt-in for forms that collect email addresses

Here’s how double opt-in works. Someone submits an email address. It doesn’t count as confirmed yet. They have to click a link first, sent to that same address. This fixes two problems at once. First, nobody can type in someone else’s email just to get past your form. Second, fake or disposable addresses get filtered out automatically, because a bot never clicks the link.

It also helps with GDPR. A timestamped click is stronger proof of consent than a checkbox.

FormGent note: If you’re connecting FormGent to Mailchimp, there’s a “Double Opt-In” toggle right in the feed settings, worth understanding before you rely on it. Turn it on, and FormGent adds the new contact to Mailchimp with a pending status, which triggers Mailchimp’s own confirmation email before the person is fully subscribed. Turn it off, and they’re added as subscribed immediately. That’s a real, working double opt-in flow, it’s just running on Mailchimp’s side rather than gating your FormGent submission itself. Our guide to building a Mailchimp signup form in WordPress walks through exactly where that toggle lives and how to set it up. If you want the confirmation step to live inside the form submission itself rather than handled through an email-marketing integration, that currently takes a custom-built step of your own.

Part 3: Validate and Sanitize Every Submission

10. Understand validation vs. sanitization, and never trust the client-side check alone

Validation and sanitization do two different jobs, and your form needs both. Validation checks the shape of what someone typed: a phone field should hold only digits, an email field should look like an email address. Sanitization comes after — it strips out or encodes anything dangerous, like a script tag hiding in a text field, before that data ever reaches your database or gets shown to someone else. Skip either one and you leave a gap.

Here’s where people get tripped up. If your validation only runs in the browser, in JavaScript, it’s not really protecting anything. Anyone can open their browser’s developer tools and turn it off in seconds. A bot doesn’t even need to bother — it can skip your form entirely and post straight to the submission endpoint, developer tools or not. That doesn’t mean client-side validation is pointless. It gives real visitors quick feedback before they hit submit, which is genuinely useful. Just don’t mistake that convenience for security. The check that actually protects your site is the one running on your server, where nobody visiting your site can switch it off.

How modern form plugins handle this: Most WordPress form plugins today, FormGent included, accept submissions through a public REST API endpoint instead of the older admin-post.php approach. That endpoint has to be open to visitors who aren’t logged in — otherwise a public contact form couldn’t work at all. So the question isn’t whether the endpoint can be reached by anyone. It can, and it’s supposed to. The real question is what happens between “the endpoint is reachable” and “the endpoint accepts a submission.” That gap is filled by a response token or nonce, server-side validation, and whatever spam defenses you turned on back in Part 2. When you’re sizing up a form plugin’s security, ask about that gap — not whether the endpoint itself is locked down, since a public endpoint being reachable is completely normal.

WordPress has its own version of this idea built in: the nonce system, using wp_create_nonce() and wp_verify_nonce(). It’s meant for logged-in, admin-side actions — a one-time token tied to one action and one user, and it stays valid for 12 to 24 hours by default. Even WordPress’s own documentation warns against leaning on a nonce by itself for access control. A nonce proves the request wasn’t forged. It doesn’t prove the person making the request is allowed to do what they’re asking — that’s a separate check you still need to make.

Developer note: If you’re building custom logic on top of a form plugin, check whether it gives you a filter you can hook into right before a submission gets saved. FormGent has one: formgent_before_store_form_response. It fires before the response is stored, and you can use it to block the submission outright — return a WP_Error from it, and FormGent rejects the submission with a proper error response instead of saving it. This isn’t a theoretical hook either. FormGent already uses it internally for its own OTP verification feature in Pro. If you need a custom validation rule, a business-specific check, or your own rate limiter, this filter is where it goes.

Part 4: Secure File Uploads

11. Secure your file upload fields by MIME type, not just extension

No field on your form carries more risk than a file upload field. Checking the file extension alone won’t protect you. An attacker can rename a malicious script from shell.php to shell.jpg, and an extension-only check will let it through without any trouble. What actually matters is checking the file’s real content type, called its MIME type, instead of just trusting the name someone typed.

Some extensions should never be allowed on a public form, no matter what the form is for: .php, .phtml, .pht, .phar, .exe, .sh, .js, .htaccess, .py, .pl, .cgi, .asp, .aspx, .jar, .bat, .cmd. Beyond that short list, match the restriction to the job. A form that only needs images should accept image MIME types and nothing else. A form collecting resumes should accept PDF or DOC/DOCX and stop there. Don’t leave a file upload field open to “any file type” unless you have a real reason to.

FormGent note: FormGent’s File Upload field lets you set which file types it accepts (JPEG, PNG, GIF, and PDF by default), plus a file size limit and a file count limit. We checked how FormGent enforces this end to end. On the server side, uploads run through WordPress core’s own upload handler, which already excludes the dangerous extensions listed above by default, so a bare .php or .exe disguised as an image won’t get through regardless of what’s configured on the field. Where it’s worth paying closer attention: the field’s own custom allow-list (say, restricting one specific field to PDF only) is enforced in the visitor’s browser rather than passed through to that server-side check, so a request that bypasses the browser could still land a file type outside your specific list, as long as it’s still on WordPress’s own default list. For a form handling sensitive uploads, treat the field’s allowed-types setting as a helpful guardrail for real visitors rather than your only line of defense, the same way we described client-side validation back in point 10. Haven’t added this field to a form yet? Our guide to adding file upload to a WordPress form walks you through it.

12. Limit file size and count, and keep uploads out of direct execution paths

File type isn’t the only thing to restrict. Also cap how large a single file can be, and how many files one submission can include. Skip the size limit, and a single oversized upload can fill up your server storage or slow your site down for every other visitor. That’s a basic denial-of-service risk, and it doesn’t take any real hacking skill to trigger it.

Where you store those uploads matters just as much. By default, anything inside your standard /wp-content/uploads/ folder can be reached directly by URL. For sensitive files, a better setup is to store them outside the public web root and serve them through a script that checks permissions first, before handing the file over. If your files have to stay inside the uploads folder, block PHP execution there. That way, even if a disallowed file somehow lands in that folder, it can’t run as a script.

How you block PHP execution depends on your server. On Apache with mod_php, an .htaccess rule like php_flag engine off does the job. But if you’re on Nginx, or on Apache with PHP-FPM (which is now the default on a lot of managed WordPress hosting), that same rule gets silently ignored — it just doesn’t do anything. In that case, you need an equivalent location block in your Nginx config, or a <FilesMatch> rule paired with Require all denied. Not sure which setup your host uses? Ask them before you assume an .htaccess rule is actually protecting anything.

Part 5: Protect the Data After It’s Submitted

13. Control who can view, export, and delete form entries

Your form entries hold names, emails, phone numbers. Sometimes much more sensitive data than that. So ask a simple question: who can actually see this inside your organization? Treat it like any other sensitive content in your WordPress dashboard.

Ask this about any form plugin you use. Does it lock entries to admins only? Or does every Editor get access by default? Now think about a trickier case. Say a support person needs to see entries, but should never delete or export them. Can the plugin do that? Or is full Editor access your only option, even just to let them look?

FormGent note: FormGent builds its own set of capabilities for forms, reading, creating, editing, deleting, and publishing, and locks them down by default rather than handing them out loosely. Only the Administrator role gets these automatically, along with any role that already carries WordPress’s manage_options capability. An Editor gets nothing by default, and neither does any other role, unless it’s already been granted that capability. That’s a deliberately conservative default, worth knowing if your team assumed Editors could see entries.

There’s no settings screen today for building a more granular, limited “form manager” role (view-only access for a support person, say) directly from the dashboard. Getting there currently takes a developer adding that access through code. Know this upfront if your team needs separate, narrower roles for forms or entries.

14. Handle GDPR and data-privacy basics properly

Are you collecting personal data from visitors in the EU? Then a few things need to be in place. Actually, most sites should have these anyway, even outside the EU. You need clear consent at the point someone submits the form. You need a way to find and delete one person’s data on request. And ideally, some kind of retention policy, so entries don’t just sit there forever by default.

FormGent note: FormGent gives you a GDPR consent checkbox field you can add to any form, and it records that consent the moment someone submits, giving you a real, timestamped record to point to. What it doesn’t yet connect to is WordPress’s own built-in Personal Data Exporter and Eraser tools, the ones designed to handle a real data request when someone asks “what do you have on me” or “delete everything you have on me.” We checked specifically for this connection, since it’s a reasonable thing to expect, and found it isn’t there yet. In practice, that means handling a deletion or export request today is a manual step: you go find the person’s entries on the Responses screen yourself rather than clicking one button. The same goes for retention, there’s no automatic expiry or auto-delete, so entries stay until someone removes them. Worth building into your own quarterly review habit (see the next section) until that changes.

Audit Your Connected Integrations Too

A form is only as secure as everything it connects to. Does your form send data to Zapier, Google Sheets, a CRM, or Slack? Then that connection is part of your form’s security too. It’s not a separate thing to worry about later.

Think about the quiet ways data can leak out. An old API key with more access than it actually needs. A Zapier automation nobody has checked in a year. A webhook still pointing at a service you stopped using. Each one is a way submitted data can end up somewhere you never intended.

So once every quarter, go through every integration attached to a form that collects anything sensitive. Ask two things each time: do you still need it, and are its credentials still locked down tight?

Bonus: Security Checks Specific to Multisite Installs

Running WordPress multisite? Agencies managing several client sites from one install often are. Two things are easy to miss here.

First, network-wide plugin settings can override what looks like a per-site setting. So a security option might look turned on for one site, but the network level is actually the one controlling it.

Second, roles and capabilities don’t always work the way you’d expect from a single-site install. This matters most for custom capabilities, the kind a plugin like FormGent registers. Don’t assume single-site behavior carries over. Test it directly on your multisite install instead.

How to Tell If Your Form Has Already Been Abused

Everything above is about prevention. It’s worth knowing what to check if you suspect something’s already gotten through:

• An admin or editor account you don’t recognize. A new user with elevated permissions that nobody on your team created is one of the clearest signs of a compromise.
• A sudden spike in outbound spam appearing to come from your own domain. This can mean your form (or your SMTP setup) is being used to relay spam.
• Entries containing script tags or unusual HTML. If sanitization has a gap somewhere, this is often the first visible symptom.
• Unfamiliar files in your uploads directory, especially ones with executable extensions that shouldn’t be there given your file-upload field’s configuration.
• An unexplained jump in submission volume that doesn’t match any real campaign or traffic spike you’re aware of.

If you spot any of these, change your admin passwords immediately, review recently modified files, and check your form plugin’s changelog for any security fixes you might have missed.

How Many of These Do You Actually Need?

Site type	What to prioritize
Personal site or portfolio, low form traffic	HTTPS, updates, a honeypot or built-in token check — that’s usually enough
Small business site, moderate traffic	The above, plus CAPTCHA or Turnstile, and entry access control if more than one person manages the site
High-traffic, e-commerce, or anything handling payments	All of the above, plus a third-party spam filter, strict file-upload restrictions, and a documented data-retention approach

Stacking every item on this list onto a low-traffic personal contact form is overkill that mostly just adds friction for real visitors. The goal is matching your protection to your actual risk, not maximizing the number of layers.

Does Your Form Plugin Itself Have a Security Track Record?

Before you trust any plugin with sensitive form data, do one quick check first. It takes about a minute. Does the developer publish a security-disclosure page? And what does its CVE history look like on a tracker like WPScan or Patchstack?

A developer with a clear “report a security issue” process, and a habit of patching disclosed issues fast, is a much better sign than one with no visible process at all. This applies no matter which plugin you’re using. Do this five-minute check either way.