Easy to setup and use
Got the rules up and running in no time.
Excellent value for money, not sure why other reviewers are complaining given how cheap these rules are
- Leave a Comment |
- Mark review as helpful
Lack of visibility limits usability
I agree with other reviewers that the ability to understand why a request is counted or blocked is paramount.
In the current scenario we will be required to create custom rules to detect and allow any false positives, in order to have working solution. It would be much more useful to at least output the rule and condition that was triggers, along with the request. It would be good to be able to disable a specific rule if it was triggered.
I understand that we should not be able to list the actual rule details, but not having a list of the rule coverage also seems bad.
This box is just a bit too black for my liking. Knowing what protection is in place is a cornerstone of good security. I don't have that with this offering.
Same considerations as last reviewer
Same considerations as last reviewer, however, you can do an "Override to Count" and see request samples, to find things to white list. However, you don't know which condition triggered the "block".
Very much a Black box.
For our testing with "Override to count" in Production, I only found it blocking valid transactions for us.
Not able to see conditions
- Not being able to see actual conditions defined in the ruleset makes it too hard to white list URLs for specific OWASP conditions. Wish there is a place to see all readonly conditions of this ruleset.
- We can see requests getting blocked but we don't know why. The samples just show the Ruleset name and not the actual reason for blocking the requests. Like "SQLi" or "XSS" or "Force browsing" etc.,
Overall, If I subscribe to this ruleset, all of it seems like a Blackbox and requests are getting magically blocked, which is not good.