Guide · Cybersecurity
WAF Rules for API Protection
Use WAF rules to protect your API. Block bad user agents, datacenter IPs, and known attack patterns.
Edge WAF rules are Infrastructure controls that complement AuthN and rate limits. Primary control: Infrastructure
Stop junk before it reaches origin
A WAF evaluates user agent, IP reputation, path, and attack signatures—and blocks or challenges before your API pays for the request. One team added Cloudflare rules for known scrapers and datacenter ranges next to rate limits; abuse fell ~90% with zero app deploys.
Rules that earn their keep for APIs
Block or challenge curl/wget/headless agents on sensitive routes (allowlist partners who need them). Challenge datacenter ASNs if your clients are browsers/mobile, not servers. Combine with rate-limit rules on `/api/`. Optional geo blocks for regions you don't serve. Enable managed SQLi/XSS rule groups as a baseline, then tune false positives.
Actions: block for APIs, challenge when humans might be real, log-only while you calibrate.
Defense in depth, not a silver bullet
WAF ≠ auth and ≠ wallets. APRF Infrastructure treats edge filtering as one layer beside authentication and cost ceilings. Wire WAF, then prove 429/block metrics move when you simulate a scraper.
Next: Infrastructure
Open the related pillar specification for mandatory checks, artifacts, and pass conditions. Self-attest is optional.
Related
Frequently asked questions
- What WAF rules should I use for API protection?
- Block known bad user agents (scrapers, headless browsers). Consider blocking datacenter IPs. Use rate limiting. Add managed rules for SQLi and XSS.
- Should I block datacenter IPs for my API?
- It depends. If your API is for end-users only, blocking datacenter IPs can reduce abuse. If your API is for servers (e.g., B2B), you'll need to allow them.
- What is the difference between WAF and rate limiting?
- WAF blocks based on request characteristics (user agent, IP, pattern). Rate limiting caps request volume. Use both for defense in depth.