Web Application Firewall (WAF)

A WAF inspects HTTP/HTTPS traffic to your site and blocks malicious requests before they reach your application. It protects against common web attacks (SQL injection, XSS, file inclusion, brute-force, credential stuffing), enforces rate limits, and can apply “virtual patches” while you fix code or plugins.

How it works

  • Rule sets: Managed vendor rules + OWASP CRS detect attack signatures and anomalies.
  • Custom rules: Match on URL, method, headers, cookies, body, country/ASN, IP reputation.
  • Actions: Block, challenge (JS/CAPTCHA/Turnstile), rate-limit, log only, or bypass.
  • Scoring/Anomaly detection: Multiple low-confidence signals combine to a block score, reducing false positives.
  • Positive security: Allow-lists for known-good paths/clients (e.g., payment webhooks, admin IPs).
  • Bot management: Fingerprinting and behavior analysis throttle scrapers and credential stuffers.

Edge vs. origin WAF

  • Edge/CDN WAF: Globally distributed, shields origin bandwidth, easy to enable; ideal for most sites.
  • Origin WAF (e.g., ModSecurity/NAXSI): Fine-grained control near your app; useful when traffic must stay private or for internal apps. Many teams use both.

What to protect (typical rules)

  • Auth endpoints: wp-login.php, wp-login AJAX, /my-account auth—limit attempts per IP/user, require challenge after failures.
  • XML-RPC: Block entirely or allow only specific methods/clients; hard-rate limit system.multicall.
  • File uploads: Enforce size/MIME/extension whitelists; scan for malware; strip PHP from media paths.
  • Query strings & payloads: Block SQLi/XSS patterns, path traversal (../), SSRF indicators, and oversized bodies.
  • Admin paths: Restrict by IP, country, VPN, or mTLS (client certificates) for privileged panels.
  • APIs/Webhooks: Allow-list provider IPs or verify HMAC signatures; exempt from generic bot/rate rules.

Tuning & lifecycle

  1. Start in log/“simulate” mode: observe matched rules for a week.
  2. Create exceptions for legitimate noise (e.g., search terms triggering XSS rules).
  3. Enable blocking gradually, beginning with high-confidence rules and auth protections.
  4. Version and test rule changes in staging; keep change history.
  5. Review alerts & logs weekly; prune noisy rules; add virtual patches for new CVEs.
  6. Pair with 2FA for admin accounts; WAF isn’t a substitute for authentication hygiene.

WordPress / WooCommerce specifics

  • Brute-force: Rate-limit wp-login.php and XML-RPC; challenge after N failures; consider allow-listing your team’s IP/VPN.
  • Cart/Checkout: Never challenge or block legitimate POSTs—exclude payment provider IPs and return URLs from bot checks and heavy rules.
  • Search & filters: Some product filters use rich query strings; add targeted exceptions for XSS/SQLi rules if they cause false positives.
  • Uploads: For /wp-admin/async-upload.php and media endpoints, restrict to authenticated users and validate MIME types.
  • Headless/API: If exposing wp-json, rate-limit and disable schema discovery for anonymous users if not needed.
  • CDN interplay: Ensure WAF bypass rules don’t also bypass necessary cache/WAF security headers; maintain consistent IP headers (X-Forwarded-For).

Operational best practices

  • Least privilege: Only security team edits WAF; application team proposes changes via tickets/PRs.
  • Rule granularity: Prefer path-specific rules to broad site-wide blocks.
  • Rate limits: Separate buckets for login, search, and APIs to avoid collateral damage.
  • Emergency switch: Keep a “Kill switch to log-only” for incident triage.
  • Monitoring: Track block rate, false positive rate, top rules hit, and auth failure trends.
  • Reporting: Map WAF events to incidents; store logs centrally (SIEM) with request samples (sans PII).

Common pitfalls

  • Blocking payment/shipping callbacks (no allow-list/HMAC).
  • CAPTCHA/challenges on checkout → abandoned carts.
  • Leaving XML-RPC open to brute-force.
  • One giant global rule set with no tuning → false positives and silent revenue loss.
  • No staging tests → breaks after plugin/theme updates.

KPIs

  • Credential stuffing success rate (should approach zero).
  • False positive rate on checkout/auth (<0.1%).
  • Blocked attack volume by type (SQLi/XSS/brute-force).
  • Time to virtual patch for new CVEs (<24h).
  • Login abuse metrics: attempts/IP, challenges solved, lockouts.