Edge Security Strategy: CDN, WAF, and Bot Management That Earn Their Cost
A WAF in monitoring mode protects nothing. Most edge security spend fails on configuration, not capability.
Edge security is one of the few areas where the capability purchased and the protection delivered diverge dramatically. Almost every enterprise has a CDN with a web application firewall. A large proportion run it in monitoring mode, indefinitely, because someone once blocked legitimate traffic and the enforcement was never re-enabled.
The result is expensive, well-instrumented observation of attacks that could have been stopped.
Lock down the origin first
Edge protection is trivially bypassed if the origin accepts direct traffic. Attackers find origin addresses through historical DNS records, certificate transparency logs, and misconfigured subdomains, then connect straight to it.
Restrict the origin to accept connections only from your CDN provider's network ranges or through an authenticated tunnel, and verify it from an external network. This single step often provides more real protection than the entire WAF rule set.
Tune the WAF, then enforce
Move to blocking deliberately rather than avoiding it:
- Run in monitoring mode long enough to cover a full business cycle, including month-end and campaign traffic.
- Review triggered rules and suppress false positives per rule and per path, not globally.
- Enable blocking first on high-confidence rule sets and highest-risk endpoints — login, admin, checkout, file upload.
- Expand progressively, watching error rates and support volume after each change.
- Add a virtual patching capability so a newly disclosed application vulnerability can be mitigated at the edge while a fix is developed.
Virtual patching is the most under-used WAF feature and often the most valuable, because it converts an emergency deployment into a scheduled one.
Protect APIs explicitly
| Control | Purpose |
|---|---|
| Schema validation at the edge | Rejects malformed and unexpected payloads |
| Per-client rate limiting | Limits scraping and enumeration |
| Authentication enforcement | Stops unauthenticated access to internal endpoints |
| API discovery | Finds undocumented endpoints in live traffic |
| Response size and error monitoring | Detects data exposure and probing |
API discovery matters because most organisations have endpoints in production that appear in no inventory — typically internal or legacy versions that were never decommissioned.
Bot management with intent, not blanket blocking
Not all automation is hostile. Search engine crawlers, monitoring tools, partner integrations, and increasingly AI assistants all identify as bots, and blocking indiscriminately damages visibility and partnerships.
Classify by intent and apply differentiated policy: allow verified beneficial crawlers, challenge unknown automation on sensitive endpoints, and block credential stuffing, scraping of pricing and inventory, and inventory hoarding. Decide your position on AI crawlers explicitly rather than by default — it is now a commercial decision about discoverability, not purely a technical one.
DDoS readiness is procedural too
Volumetric protection is largely automatic with a competent provider; application-layer attacks require preparation. Know your normal traffic baseline, have rate limits and challenge policies ready to activate, prepare a static or degraded mode for the site, and know exactly who to contact at the provider and what your plan level entitles you to.
Rehearse the escalation once. Discovering your support tier during an attack is a poor time to learn it.
Measure protection, not traffic
Report the proportion of traffic in blocking versus monitoring mode, false positive rate and time to resolve them, origin exposure verified as closed, API endpoints under policy versus discovered, and bot classification accuracy. Requests-blocked totals look impressive and say nothing about whether the endpoints that matter are actually enforced.
Frequently asked questions
Why do WAFs fail to protect?
Because they are commonly left in monitoring mode indefinitely, recording attacks instead of blocking them.
How do we tune safely?
Monitor across a full business cycle, suppress false positives per rule and path, enable blocking progressively from high-confidence rules and high-risk endpoints, and watch error rates.
Is the origin still exposed behind a CDN?
Yes unless locked down — restrict it to the CDN's network or an authenticated tunnel and verify externally.
Should we block AI crawlers?
That is a commercial decision about discoverability. Decide it explicitly and implement per crawler rather than leaving it to default rules.