Do I need a firewall for WordPress, or is a malware scanner enough?

A firewall and a scanner do different jobs, and most WordPress sites are better off with both kinds of cover. A firewall looks at each request before WordPress handles it and refuses the ones that match an attack. A scanner looks at what is already on the site: files, accounts, settings and plugin versions. A firewall cannot tell you that someone planted a backdoor last month. A scanner cannot stop the request that plants it.

The firewall does not have to be a WordPress plugin. For many small sites it comes from the host or from a CDN in front of the site.

What a web application firewall does

A web application firewall (WAF) sits between the visitor and your site. For every request it compares the address, the parameters, the form fields and the headers with a set of rules, then blocks the request, slows it down or lets it through. Typical rules catch SQL injection and cross-site scripting attempts, requests for files of plugins with known holes, floods of login attempts and bad bots.

It can run in three places:

• At the edge, in a CDN or reverse proxy that all traffic passes through. A blocked request never reaches your server, so it costs your server nothing.
• On the server, as a module of the web server that the host runs for every site it serves.
• Inside WordPress, as a plugin. It sees a request only after it has reached your server and PHP has started, and it uses your hosting's CPU and memory on every request. In return it knows WordPress: who is logged in, and which plugin a URL belongs to.

What a firewall cannot do

A firewall judges requests one at a time, by rules. Some gaps stay open whatever the rule set:

• A login with a stolen but valid password looks like the owner signing in.
• A hole in a plugin that nobody has written a rule for yet goes through. Rules follow published vulnerabilities, so there is always a window.
• Code that is already on the server keeps running. A firewall installed after a break-in does not remove the backdoor.
• Changes made from an administrator account, a hijacked one included, are ordinary traffic to a firewall.

This is why updates come first. A firewall rule for a known hole buys time until you update. It does not replace the update.

What a malware scanner does

A scanner checks the state of the site. A good one for WordPress:

• compares WordPress, plugin and theme files with the official copies on WordPress.org for your version, which finds changed files without guessing,
• looks for PHP files in the uploads folder,
• lists administrator accounts and notices new ones,
• checks plugin and theme versions against published vulnerabilities,
• finds backups and copies of the configuration that anyone can download.

It stops nothing during an attack. It tells you afterwards what changed and what to do. How to read such results is covered in how to check a website for malware.

Where a firewall can come from

Your host. Many hosts filter requests for every site on their servers. Ask them in writing: is there a web application firewall in front of my site, who updates its rules, and can I see what it blocked? If the answer is yes, you may not need another layer.

A CDN in front of the site. A CDN such as Cloudflare sits between visitors and your server and can filter requests at the edge. On 19 October 2026 Cloudflare's WAF documentation said its Free Managed Ruleset is available on all Cloudflare plans and covers high-impact, widely exploited vulnerabilities. After you set a CDN up, check two things. Your server should not answer requests that skip the CDN and go straight to its IP address. Your login protection should see the visitor's address, not the CDN's.

A firewall plugin. This is the route when the host offers nothing and a CDN does not fit. Before you choose one, look in its listing or documentation for:

• whether it loads before other plugins, so it sees a request before the vulnerable code does,
• how often its rules are updated, and whether free users get new rules at the same time as paying ones,
• a learning or record-only mode, so you see what it would block before it starts blocking,
• its effect on your server. Measure the load time before and a day after.

Keep one firewall per layer. Two firewall plugins on one site do the same work twice, and when a customer gets refused, it is hard to tell which one did it.

Which one do you need

• Does your host already filter requests? Then a scanner and good habits cover the rest.
• Do you run a shop, a members' area or forms that many people use? A firewall at the edge makes sense there, because there is more to attack and more to lose.
• Do you update plugins within a few days of a release? Then a firewall mostly catches noise. If updates wait for weeks, it covers exactly that gap.
• Would you find out if a file on the server changed tonight? If not, you need a scanner whatever else you have.

Neither of them replaces a backup kept away from the server. After a break-in, a clean copy is what brings the site back.

What to watch out for

• False blocks. A firewall that refuses your payment provider's callbacks or messages from the contact form costs you orders, and you see no error. Read its log for the first few weeks.
• A firewall as a reason to put off updates. The rule can arrive later than the attack.
• "Cleaning" promised as part of a plan. Removing malware is work on files, done by someone who reads them. Ask who does it and how they find out how the attacker got in. Otherwise the same way in stays open.

Where Ensomedia Security fits

Ensomedia Security is mainly a scanner with login protection and hardening switches. Since version 1.1.26 it also has a Request firewall, off until you turn it on. It is a set of local rules on your server, not a cloud WAF, and it does not clean a hacked site.

How it compares with the checklist above:

• It loads early. A must-use file checks each request before ordinary plugins load, and on hosts that run PHP through CGI or FastCGI the Load before WordPress setting starts it before WordPress through the .user.ini file.
• Its rules arrive with plugin updates and are the same for every site, because the plugin has no paid version. They cover common injections and executable uploads, IP, range and country blocks, request and 404 limits, and narrow exceptions. Behind Cloudflare, country blocking works with the Cloudflare address ranges the plugin has shipped since version 1.1.28. Ordinary traffic (WooCommerce checkout, the block editor, the REST API, comments, contact forms and sign-in) is covered by tests and passes with every rule on.
• It has a Record only mode. Start with it, read the firewall history for a week or two, then switch to Block.
• It runs on your server, so a blocked request has still reached your hosting and started PHP. It does not take load off the server the way a filter at the edge does. It sends no request data anywhere, and its history stays on your site for up to 30 days.

A firewall at your host or CDN and this one work on different layers, so they can run together. Do not run it beside another firewall plugin. If it ever locks you out, the plugin's FAQ explains how to turn it off without the dashboard.

What else it does:

• It checks official checksums first. WordPress core, directory plugins and directory themes are compared with the files WordPress.org published for your version.
• It never rewrites the site on its own. Files, users and settings change only when you press a button or turn on a switch. A file with a finding of medium severity or higher can go into quarantine with one button, and Restore puts it back. Since version 1.1.21 one button replaces a changed core, plugin or theme file with its WordPress.org original and keeps the changed file in quarantine, so restoring it undoes the repair. Since version 1.1.25 it also removes code injected into a theme, a custom plugin, the uploads folder, posts or options: it shows the exact change, makes a backup, applies it only when you approve it, and every cleanup can be undone. Any other clean-up it explains is for you, your developer or your host.
• It limits failed logins per address and per user name. Only the connection's own address counts, never a header a request can fake. Behind a CDN or proxy you list its addresses as trusted proxies and choose the header that carries the visitor's address.
• Since version 1.1.27 it has optional sign-in checks: passkey sign-in without a password, a bot check on the login, registration and password reset forms, refusing passwords found in data breaches, a hidden login address, and spam traps for comments, registration and contact forms. All of them are off until you turn them on.
• It has hardening switches, all off until you turn them on: the file editor, XML-RPC, a block on PHP in uploads, and security headers. A header your server, CDN or another plugin already sends is left as it is.
• It has virtual patches, which are narrow on purpose. With the live threat feed turned on, a small must-use file can stop a request that exploits a known vulnerability of a plugin you have installed, for as long as your installed version is affected. The patches block once you accept the offer to turn on protection after activation. Otherwise they only record matching requests. It does not inspect all traffic the way a firewall does.

The checks, the daily scheduled scan and the email alerts are free, with no account and no limits. The firewall, the sign-in checks, the live threat feed, the vulnerability lookup and the AI second opinion stay off until you turn them on. You can find the plugin in the WordPress.org directory as Ensomedia Security, and the plugin page lists what each optional service sends. A side-by-side comparison with Wordfence, with what each plugin has and lacks, is on the comparison page.

Check your site from the outside. Enter your address at shieldwave.io. It takes about 90 seconds and needs no password and no plugin.