Hey there! It's reassuring to see it catching the basic SQLi probes, especially for an internal tool. That's definitely its sweet spot - the kind of obvious, noisy stuff that floats around the internet.
Your two points about false positives and coverage for subtle attacks are really the heart of the matter for a built-in tool. Tweaking sensitivity for a dynamic parameter is a perfect example of the trade-off. You're already doing the work of tuning, which means you're starting to understand your own app's behavior, and that's good. But it's also the exact moment you start wondering, "what else am I not seeing?"
For a simple, low-traffic server, that basic filtering might feel like enough, especially if you're the only one using it. The concern I've seen, though, is that it can create a kind of tunnel vision. The dashboard shows blocked attacks, which is great, but you don't get a log of the legitimate-looking sequences that might be probing for business logic flaws over time. Since you're coming from a Datadog/Grafana mindset, you might find it useful to think about what metrics *aren't* being collected by the WAF itself. How would you even chart a slow, low-and-slow data scrape using valid session IDs? That's the subtle part it likely won't flag, and your existing monitoring wouldn't either.
Let's keep it real.
That's a great way to put it - "tunnel vision on the dashboard." I've seen the exact same thing happen when teams lean too hard on their cloud provider's WAF.
You're spot on about the missing metrics. It's like monitoring a door with only a "forced entry" alarm, but no log of people rattling the handle. For a slow data scrape, you'd need to instrument your app to track request patterns per session or IP over time, something the built-in tools just don't do. My Grafana board for a similar service ended up with a panel for "GET request sequences per unique auth token in a 5-minute window" just to catch that kind of probing.
It feels like you're building a second, specialized detection system on the side, which kinda proves the point about the first layer's limits.
K8s enthusiast
Your point about tuning a parameter because it's "too dynamic" is the exact moment you transition from using a black box filter to actively managing a security control. That's the built-in WAF's real job - not stopping attacks, but forcing you to learn your own application's unique attack surface.
The subtle attack coverage question often comes down to session awareness, which most built-in tools lack. They might catch the malformed request, but not a legitimate user session slowly scraping your data endpoint by endpoint. For that, you'd need to build a separate layer of instrumentation, which circles back to your monitoring background. You'd likely end up adding panels in Grafana for request sequencing or abnormal parameter access rates, essentially creating the missing logic yourself.
So, is it enough? For blocking generic, automated probes, yes. For protecting the actual business logic of even a simple internal dashboard, you'll probably find yourself supplementing it with custom monitoring rules anyway.
For a low-traffic internal dashboard, catching the SQLi probes is all you really need from a built-in tool. Your tuning exercise is the key point.
That tweak you made for the dynamic parameter? That's you defining the application's normal behavior, which the WAF can't know. For subtle attacks like session-based data scraping, it's blind. You'd need to build that logic into your app monitoring, which you already know how to do with Grafana.
So it's enough until the first time you wonder "what's normal for this user session?" Then you're back to building your own panels.