docs: add warnings and a use case on false positive management #247
Conversation
|
thanks for your PR - please make a bit more informative comment under the PR. For example, please see this. The two relevant questions are "why" and "what", with one-one sentences. Thank you again. |
|
@airween done, does this sound good to you ? |
airween
left a comment
airween
left a comment
There was a problem hiding this comment.
I'm not a native English speaker so it's not the best idea to give a review, but I made a suggestion.
Cc: @theseion, @RedXanadu.
Yes, excellent! Thank you! |
| ``` | ||
|
|
||
| {{% notice %}} | ||
| If, for optimization purposes, you need to use dynamic variables - for example, to efficiently filter Base64 variants - be aware that this directive supports dynamic variables, like so: |
There was a problem hiding this comment.
This notice is more confusing than helpful, I think. It's unclear to the reader, where the variable base64_ARGS comes from. I like the example though, so maybe transform this into a separate scenario, and include setting base64_ARGS.
| This type of broad exclusion must be avoided at all costs for most standard web application use cases. | ||
| In such contexts, you should never do this. |
There was a problem hiding this comment.
| This type of broad exclusion must be avoided at all costs for most standard web application use cases. | |
| In such contexts, you should never do this. | |
| Even though the decision in this example may seem trivial, rule exclusions _always_ carry a risk. It is important to understand the risk of disabling a rule, i.e., which attack vectors become available by disabling the rule, even if only a single target is affected. |
Co-authored-by: Ervin Hegedus <[email protected]>
Co-authored-by: Max Leske <[email protected]>
|
Please work through the open comments @touchweb-vincent. |
|
@theseion I was waiting for your point of view before committing the changes. The changes have now been committed. |
3 participants
Hello,
what
This PR adds explicit warning notices to several rule-exclusion examples and documentation sections.
These notices remind users that:
why
To help users avoid unsafe tuning practices that could compromise the effectiveness of CRS.
Some examples and documentation snippets may look harmless, but when reused without proper context they can lead to overly broad exclusions or rule bypasses.
Adding warnings provides clear guidance about when an example is for demonstration only, and when it should never be used in production.