Layered WordPress hardening

Layered WordPress hardening: Cloudflare, wp-config, and origin shielding#

If your WordPress site shows intermittent slowness or sudden traffic spikes from countries unrelated to your business (for example, China, Russia, or Taiwan), you are likely being targeted by recon bots or brute-force traffic.

This guide documents how to use Cloudflare's free plan to implement defense in depth, filtering malicious requests before they reach your origin server.

My operational goal is always the same: push hostile traffic handling to the edge, keep the origin focused on legitimate users, and reduce CPU/IO pressure with predictable behavior.

2. Bot mitigation on contact and AJAX endpoints#

Form spam abuse through admin-ajax.php pollutes inboxes and also drives CPU usage on origin.

Rule 3: AJAX request validation#

Expression:

(not cf.client.bot and http.request.uri.path contains "/wp-admin/admin-ajax.php" and http.request.method eq "POST" and not http.referer contains "dominio.com.br")

Action: Managed Challenge.

This endpoint is sensitive because many plugins depend on it. I usually deploy this in challenge mode first, monitor traffic analytics, then raise to strict blocking only after validating no legitimate flow is impacted.

4. Senior tip: origin shielding (Cloudflare IP only)#

Cloudflare configuration is useless if attackers can still hit your real origin IP directly.

Gray cloud vs orange cloud: ensure all relevant A/CNAME records are

proxied (orange cloud).

Server firewall (CSF/IPTables): accept ports 80/443 only from

Cloudflare IP ranges, denying direct public origin access.

Practical hardening cycle on the host#

In production hardening I execute this sequence:

Retrieve official Cloudflare IP ranges.
Build allow rules for 80/443.
Deny remaining direct HTTP/HTTPS traffic.
Validate domain works through Cloudflare and fails by direct origin IP.

This prevents the common false sense of security where WAF is active but origin is still exposed.

Strategic conclusion#

WordPress security should not rely only on in-app plugins (for example, Wordfence or Sucuri), which consume origin resources. Moving security logic to the edge (Cloudflare) gives near-zero added latency and reduces hosting processing cost.

From an operational perspective, the payoff is clear: less infrastructure noise, fewer intermittent incidents during peaks, and better predictability when scaling.

Was this article helpful?

Leave a quick reaction to help prioritize future technical guides:

This post is licensed under CC BY-NC.

Layered WordPress hardening: Cloudflare, wp-config isolation, and origin shielding