The GuardPress Firewall: Protection Types and Rules
The Web Application Firewall inspects every incoming request at plugins_loaded:20, before WordPress dispatches the request handler, and blocks matches with a 403 response. This article covers the protection categories the WAF enforces, how the rule engine decides what to block, and how administrators are kept from being locked out by their own firewall.
What the firewall blocks
The rule engine runs against every incoming request’s URI, query string, POST body, and headers. Six broad protection categories are checked in order:
| Category | What it catches |
|---|---|
| SQL injection | UNION SELECT payloads, boolean-blind patterns, timing-based blind patterns, common ORDER BY / GROUP BY injection shapes, comment-truncation attempts. |
| Cross-site scripting (XSS) | <script> tag injections, javascript: URI schemes in href/src attributes, on-event handler injections (onerror, onload, etc.), and encoded-payload variants. |
| File inclusion (LFI / RFI) | Path-traversal patterns (../../), php:// wrapper misuse, PHP-CGI argument-injection payloads (CVE-2012-1823 shape), and other remote-file-inclusion attempts. |
| Bad bots | User-Agent strings for known scanner and exploitation toolkits (sqlmap, nikto, masscan, nmap, acunetix, nessus, openvas, metasploit, havij, grabber, dirbuster, zmeu, webshag, w3af). See Spotting Spoofed AI Crawler Attacks for how the firewall handles crawler User-Agents specifically. |
| Rate limiting | Excessive request rates from a single IP over a short window. Protects against DDoS-lite, content scraping, and enumeration. |
| Request integrity | Null-byte injection in the request URI, invalid HTTP protocol strings, abnormally long request URIs (>2000 chars). These are almost always malformed-tool signatures. |
When any rule matches, the request is dropped with an HTTP 403 response, logged to the audit log with the specific rule name, and (if the auto-ban threshold is met) escalated to a permanent IP ban.
When the firewall runs
The firewall attaches to plugins_loaded at priority 20. That means it runs after core WordPress bootstraps but before WordPress dispatches the request to a handler (theme, plugin, REST route, etc.). Blocked requests never touch the theme or plugin code, so the WAF adds only a small overhead to legitimate requests and effectively zero to blocked ones.
For REST API and WP-CLI contexts, the firewall still runs because plugins_loaded fires in both contexts. Application Passwords, REST authentication, and CLI operations all get the same rule inspection as browser requests.
Administrator auto-whitelist
Signed-in administrators are auto-whitelisted by the firewall — requests carrying a valid administrator session cookie bypass rule checks entirely. This prevents the “I just wrote a legitimate SQL snippet in a post and my firewall blocked it” scenario, which is where every WAF eventually annoys a developer.
Non-admin users (Editors, Authors, Subscribers, Customers) do not get the auto-whitelist. Their requests are inspected normally. If a legitimate editor workflow trips a firewall rule, whitelist the specific pattern in GuardPress → Firewall → Rules rather than granting the whole role a bypass.
IP whitelist
For situations where the admin-cookie auto-whitelist isn’t enough (webhook endpoints, CI/CD deploy triggers, payment-gateway callbacks), the manual IP Whitelist bypasses every firewall rule for the listed IPs. CIDR ranges are supported. Full workflow: IP Blocking, Whitelisting, and Managing Locked-Out IPs.
Do not whitelist your general office network or a home ISP CIDR unless the ISP-assigned range is stable and small. Whitelisting a large public range gives every device on that range a firewall bypass, which is not what you want.
False positives and rule tuning
Every WAF has false positives eventually. The most common shapes on WordPress:
- WooCommerce checkout POST bodies triggering XSS rules because the customer typed a semicolon in an address field
- Elementor / Divi form submissions triggering SQL injection rules on serialized field data
- Payment-gateway webhooks triggering bad-bot rules because the calling service’s User-Agent isn’t common enough to be pre-whitelisted
- OAuth callbacks triggering file-inclusion rules on URL-encoded state parameters
The fix pattern is always: identify the specific rule that fired (audit log shows the rule name), whitelist that rule for that endpoint, keep the rest of the WAF active. Don’t disable the whole firewall to unblock one endpoint. See Firewall False Positives for the full triage flow.
- Spotting Spoofed AI Crawler Attacks: reading a critical-threat alert, and the FCrDNS check the firewall runs on crawler User-Agents
- Firewall False Positives: the triage flow when a real user gets blocked
- IP Blocking & Whitelisting: the three-list model for manual IP control
- Country Blocking + Cloudflare Real-IP: the pre-flight check before any IP-based rule is trustworthy