Question: What if the WAF rule you think is protecting your WordPress backend is actually breaking your site while leaving the real entry point wide open?
The Assumption Everyone Makes
Blocking /wp-admin/ at the firewall level sounds like solid security hygiene. The WordPress backend lives there, so keeping unauthorized users out means locking that path down. Add a skip rule for your own IP, and you’ve got a controlled access point. Bonus: it’s fast to deploy, and it feels decisive. Many people also reach for Cloudflare Zero Trust as the “modern” alternative — same goal, different tool.
What Actually Happens
A WAF rule that blocks /wp-admin/ also blocks admin-ajax.php. That endpoint lives under the same path and is used by countless plugins for legitimate front-end functionality — forms, dynamic content, AJAX-driven UI. Visitors who never touch the backend hit it constantly without knowing it. Break that, and you’ve broken parts of your site that have nothing to do with the admin area.
Meanwhile, wp-login.php sits outside /wp-admin/ entirely. It’s the actual login page — the one bots hammer. Your WAF rule doesn’t touch it. You’ve created breakage without closing the attack surface you were trying to close.
The skip rule for your own IP completes the picture: now you’re using a firewall to both block and allow access to the same path. That’s not how firewalls work. A firewall opens a gate or closes it. Using two opposing rules to manage the same resource means you’re working around the tool, not with it.
Why This Matters More Than You Think
The tool confusion here runs deeper than one misconfigured rule. WAF rules and Zero Trust are not alternatives for the same problem — they’re built for different threat layers entirely.
A firewall filters traffic. Its job is to block what shouldn’t reach your server: bad bots, hostile ASNs, known attack patterns, specific countries. That’s where WAF rules belong. They operate on traffic characteristics, not on identity.
Zero Trust operates before the request reaches your origin at all. It answers a different question: who is allowed to initiate this connection? It’s not a traffic filter — it’s an identity gate. For protecting an admin area, that’s actually the right framing. But it solves an access control problem, not a traffic problem. Conflating them means neither is configured correctly.
The practical failure mode: a WAF-based approach to admin protection requires skip rules per IP, which break the moment you travel, change networks, or share access. It also produces false confidence — you’ve done something visible, but the actual login endpoint remains public.
The Right Approach
Use each tool for what it was built for.
WAF rules are for traffic you want to block outright: known malicious IPs, hostile ASNs, countries you have no business in, bots that aren’t Googlebot. Block rules should be boring and unambiguous — one direction, no skip logic.
Zero Trust (Cloudflare Access or equivalent) is for controlling who can reach your admin interface. It removes the login page from the public internet, requires identity verification before a connection is established, and handles the IP-agnostic access problem cleanly.
Fail2Ban or CrowdSec handle the brute-force layer — they watch wp-login.php and act on repeated failures.
These layers stack. None of them replaces the others. If you find yourself writing a WAF rule to open something that another WAF rule closes, stop — that’s a signal you’re solving an access control problem with a traffic filter.