Cloudflare's managed rulesets are solid, but they're generic. The real power move is using Workers to bake your app logic directly into the edge security layer.
Think about it: you can block scrapers targeting specific endpoints, validate API request structures before they even hit your cluster, or implement geo-fencing logic that's way more granular than the standard WAF. It's like having a custom middleware that runs *before* the managed rules even fire.
Here's a simple Worker that adds a custom header check and blocks a specific pattern in a query param. Deploy this in front of your WAF.
```javascript
export default {
async fetch(request, env, ctx) {
const url = new URL(request.url);
const headers = request.headers;
// Custom rule 1: Block missing 'X-API-Key' on admin paths
if (url.pathname.startsWith('/admin') && !headers.has('X-API-Key')) {
return new Response('Access Denied', { status: 403 });
}
// Custom rule 2: Block suspicious query param pattern
if (url.search.includes('../../../')) {
return new Response('Invalid request', { status: 400 });
}
// If passes, send request to origin (or through the WAF)
return fetch(request);
},
};
```
Now your WAF handles the OWASP stuff, and your Worker handles the *you* stuff. This is a game-changer for k8s ingress too—offloads logic you'd normally put in an Istio/NGINX filter. Anyone else stitching Workers into their WAF flow? What custom rules are you running?
yaml all the things
That Worker example is a footgun. You're putting rate-limiting and path traversal detection logic into a script when both are covered and optimized in the managed rulesets.
The real value is extending with context the WAF can't see. For instance, a Worker that checks a user's tier in your database (via KV) and applies different rate limits before the request hits the WAF at all.
But mixing basic WAF logic into your custom code just creates two places to manage security rules.
Trust, but verify
You're absolutely right about the duplication point. Running your own regex for path traversal alongside Cloudflare's OWASP ruleset is a maintenance nightmare that adds latency for zero benefit.
But I think your database example touches on a bigger architectural debate. Once you start checking user tiers from KV at the edge, you're now responsible for the availability and latency of that data store in your security critical path. A failure there could mean either letting everything through or blocking all traffic.
The sweet spot might be Workers that enrich requests with internal context for the WAF itself, using custom fields. Then you keep the actual blocking logic within the managed WAF where you can track it alongside other threats.
Exactly. "Sweet spot" is usually where the real complexity lives.
That KV latency/availability point is spot on. Suddenly your edge security depends on your cold start for a globally distributed user tier cache. What's your fallback? Let everyone through as premium? Block all traffic?
Custom fields are better, but then you're just paying Workers tax to shuttle data into a WAF that still uses basic string matching. Feels like a duct tape architecture.
The real debate is whether we're just building a more expensive, fragile WAF instead of fixing the actual WAF's limitations.