DEV Community

Lia
Lia

Posted on

How to Protect WordPress with a Self-Hosted WAF

How to Protect WordPress with a Self-Hosted WAF

WordPress powers a huge share of the web and attracts a matching share of attacks: login brute force, plugin exploits, SQL injection through forms, and xmlrpc abuse. A self-hosted WAF placed in front of WordPress blocks the bulk of that traffic before it ever reaches PHP.

Why put a WAF in front of WordPress

Plugin-level security (like Wordfence) runs inside WordPress and understands WP internals. A stack-level WAF like SafeLine runs as a reverse proxy in front of the whole server, so it protects WordPress and anything else on the host — and it still works even if a plugin or theme is compromised.

Step 1 — Install SafeLine

On the host that will sit in front of WordPress:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
Enter fullscreen mode Exit fullscreen mode

SafeLine runs as a container and needs only modest resources (1 CPU, 1 GB RAM, 5 GB disk minimum).

Step 2 — Add WordPress as the upstream

Open the console at https://<safeline-ip>:9443 and add a protected site:

  • Upstream server — where WordPress actually listens, e.g. http://127.0.0.1:80 if SafeLine shares the host with the web server.
  • Domain — your WordPress domain, e.g. blog.example.com.
  • Port — the public port SafeLine listens on (80 / 443).

Then point your DNS (or firewall port) at the SafeLine host so visitor traffic reaches it first.

Step 3 — Turn on the WordPress-relevant protections

SafeLine's semantic engine already blocks SQL injection and XSS generically — that covers most WordPress form and admin attacks out of the box. Two extra levers are especially useful for WP:

  • Rate limiting on /wp-login.php and /xmlrpc.php to stop credential-stuffing and the classic xmlrpc pingback floods.
  • Bot challenge (CAPTCHA) for suspicious automated clients, so scrapers and bad bots get stopped without affecting real visitors or Google.

Step 4 — Watch the logs

The dashboard shows every request: allowed, blocked, and challenged. If a legitimate plugin endpoint trips a false positive, add a whitelist rule for that specific path rather than disabling protection globally.

SafeLine vs a WordPress security plugin

SafeLine (stack-level) WP plugin (in-app)
Protects WordPress Yes Yes
Protects other apps on host Yes No
Works if WP is compromised Yes Weaker
Free tier Community Edition (10 apps, 800 QPS) Limited

You can also run both — SafeLine at the proxy edge plus an in-app plugin is defense in depth.

FAQ

Will it break my plugins?

Generally no. SafeLine forwards normal traffic untouched; only requests that look like attacks are blocked. Tune per-path if needed.

Do I still need to update WordPress?

Yes — a WAF reduces attack surface but isn't a substitute for patching core, themes, and plugins.

Can I protect multiple WP sites with one instance?

Yes — the free Community Edition covers up to 10 apps, so several WordPress installs behind one SafeLine is fine.

Does it affect SEO crawlers?

Real search-engine bots pass through normally; only abusive automated traffic is challenged.


That's it — your WordPress site now has a self-hosted WAF filtering traffic before PHP ever runs.

Deploy it in minutes:

bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
Enter fullscreen mode Exit fullscreen mode

Top comments (0)