Protecting a WordPress site with a web application firewall

WordPress runs a large share of the web, and that is exactly why it is the favourite target of bots: a single flaw in a popular plugin opens hundreds of thousands of sites. Attacks are rarely aimed at your site; they try the same list of addresses on every WordPress they find.

What Zyre's WordPress rules block

• `xmlrpc.php`, including system.multicall calls, which let an attacker try hundreds of passwords in a single request.
• Account enumeration through the REST API (/wp-json/wp/v2/users), which hands login names to anyone who asks.
• Direct access to core files that have no reason to be called from outside: wp-config.php, wp-load.php, wp-settings.php, the PHP scripts in wp-includes.
• PHP execution in `wp-content/uploads`: that is where a vulnerable upload form drops a malicious script.
• Known webshell names in plugin and theme folders, and the paths of historically exploited plugins.
• Plus everything the shared rules cover: injections in forms and parameters, XSS, forgotten .env, .git and backup files.

What gets through, on purpose

wp-admin and wp-login.php stay reachable: you need to log in, and the block editor calls the REST API constantly. These addresses are not closed, but their content is still inspected — an injection sent to the login page is blocked as anywhere else.

One setting to check before switching over

WordPress scheduled tasks (scheduled posts, backups, mailings) keep working: WordPress triggers them by calling its own wp-cron.php address, and that call goes through the firewall normally.

What the firewall does not replace

• Updates. The firewall filters a published flaw while you update; it does not exempt you from doing so. Zyre's threat intelligence flags known flaws in the versions detected on your site.
• Strong passwords and two-factor authentication on administrator accounts.
• Backups stored somewhere other than the site's server.