Hey everyone, I'm hoping someone can help me understand a weird situation we're having with Cloudflare's WAF.
We set up Cloudflare a few months ago to protect our web application. In the dashboard, under Security Events, we see a lot of requests with the action 'Mitigated' (mostly SQLi and XSS rules). That looks good, right? But our origin server's own monitoring (AWS CloudWatch) is still showing spikes in traffic that correlate with these attack waves, and our server logs show the malicious requests actually reaching our NGINX. Shouldn't Cloudflare be blocking these requests entirely so they never hit our origin?
Our setup is pretty standard:
- DNS points to Cloudflare (proxied, orange cloud).
- We have the Cloudflare WAF managed ruleset enabled (with most rules set to "Block").
- Our origin server IP is hidden.
Here's a sanitized example of what we see in our own origin logs that Cloudflare says it 'Mitigated':
```log
203.0.113.100 - - [15/Oct/2023:14:22:15 +0000] "GET /index.php?id=1' OR '1'='1 HTTP/1.1" 200 4523 "-" "Mozilla/5.0"
```
The IP `203.0.113.100` is a Cloudflare IP, not the real attacker IP. So the request is coming from Cloudflare's network, but with the malicious payload still intact.
I'm confused about what 'Mitigated' actually means here. Does it just mean "we logged it" or "we challenged it"? Why is the attack payload still being passed through? Are we missing a setting? Could this be a caching thing?
We're on the Pro plan. Any insight would be super helpful.
Oh, that's weird. I've been looking at Cloudflare for our own setup, and I thought 'Mitigated' meant the request was fully blocked at the edge. If it's still hitting your origin, what's the point of the WAF? That's a bit worrying for my own planning.
Could it be something with your SSL/TLS configuration on the origin? I've read that if the connection between Cloudflare and your server is using a mode like 'Full' but not 'Full (strict)', it might bypass some checks? I'm not totally sure though.
What does the actual Cloudflare Security Event log show for that specific request? Does it list a specific rule ID that triggered the 'Mitigated'? Maybe that would tell you more about what it actually did.
The 'Mitigated' label itself is the key. It doesn't always mean blocked at the edge. Sometimes it means Cloudflare performed an action like issuing a challenge, stripping a header, or sanitizing input, but the request can still be passed to your origin. You need to check the specific action taken for those events.
You're right to look at the rule ID. That's the first step. Pull a few specific request IDs from your origin logs, then cross-reference them in the Security Events log. Look at the "Action Taken" column, not just the status.
—AF
Yeah, that log snippet is the smoking gun. Seeing a Cloudflare IP means the request definitely came through their network, and the payload is still malicious.
The others are on the right track - the "Mitigated" status is too generic. You need to drill into the specific Action Taken for those events. Cloudflare's managed rules can be configured to do things like "Managed Challenge" or even "Log" by default, even if you expect "Block." A rule set to "Log" will show as "Mitigated" but still pass the request through.
Check the exact rule ID from the Security Events for a request matching that timestamp and payload. My guess is you'll find the action is "Managed Challenge" or "JS Challenge," which still results in a request to your origin after the challenge is solved (or perhaps bypassed by the bot).
So you're paying for a WAF that flags threats but still lets them hit your server? Classic. "Mitigated" is a marketing term, not a technical one.
Check your actual rule actions. "Block" is a setting, but the default action for many managed rules is often "Challenge". You're probably getting a managed challenge page served from Cloudflare, but if the bot solves it, the poisoned request continues to your origin. That's why your logs show the payload.
You need to audit every rule's *action*, not just its status. If you're on a Pro plan, you might not even have the "Block" action available for some rulesets. The pricing tier determines the real protection.
always ask for a multi-year discount
> But our origin server's own monitoring (AWS CloudWatch) is still showing spikes in traffic that correlate with these attack waves, and our server logs show the malicious requests actually reaching our NGINX.
You've got a gap between what the dashboard says and what actually happens. The "Mitigated" label is a bucket that includes several actions - "Block", "Managed Challenge", "JS Challenge", "Log", even "Skip". If your rule action is set to "Block", the request should never reach your origin. Seeing it hit your NGINX with a Cloudflare IP means either:
1. The rule that triggered is not actually set to "Block" - check the specific rule ID's action in the Security Events log, not just the ruleset-level toggle. A ruleset set to "Block" can have individual rules with "Log" or "Challenge" actions that override it.
2. You're looking at the wrong event - the "Mitigated" status might be for a different request (e.g., a rate limit or bot management action) while the SQLi request is being allowed through by a different rule.
3. The rule is in the "Skip" phase - some managed rules skip certain traffic based on criteria like IP or user-agent, and the request still gets proxied.
Pull the exact request ID from your origin log for that timestamp, then find it in Security Events. Look at the "Action Taken" column. I bet you'll find it's "Managed Challenge" or "Log". If it's "Log", that's your problem - Cloudflare is literally just recording the hit and passing it through. Happens a lot with the OWASP core ruleset on the Pro plan because Block is not available for all paranoia levels.
One more thing: check your WAF skip rules. If you have any rule that says "Skip the remaining rules if [condition]", that could be allowing the malicious request through even though the managed ruleset is enabled.
—davidr