Skip to content

docs: add warnings and a use case on false positive management #247

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
touchweb-vincent wants to merge 12 commits into
base: main
Choose a base branch
from
Open

docs: add warnings and a use case on false positive management #247

Changes from 6 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
d537dcf
Update 2-3-false-positives-and-tuning.md
touchweb-vincent Nov 4, 2025
567d7f4
Merge branch 'main' into patch-1
airween Nov 4, 2025
7b93196
Merge branch 'main' into patch-1
airween Nov 5, 2025
1e2cc98
Update content/2-how-crs-works/2-3-false-positives-and-tuning.md
touchweb-vincent Nov 6, 2025
a50a3dd
Update content/2-how-crs-works/2-3-false-positives-and-tuning.md
touchweb-vincent Nov 6, 2025
abc9b66
Update 2-3-false-positives-and-tuning.md
touchweb-vincent Nov 9, 2025
8917b90
Update 2-3-false-positives-and-tuning.md
touchweb-vincent Nov 10, 2025
51cd0db
Merge branch 'main' into patch-1
theseion Nov 11, 2025
ce83dd7
Merge branch 'main' into patch-1
touchweb-vincent Nov 13, 2025
00c5bf9
Merge branch 'main' into patch-1
touchweb-vincent Nov 19, 2025
c6af788
Merge branch 'main' into patch-1
touchweb-vincent Dec 7, 2025
5972556
Merge branch 'main' into patch-1
EsadCetiner May 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion content/2-how-crs-works/2-3-false-positives-and-tuning.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -221,6 +221,12 @@ SecRuleRemoveById 933151

**Scenario:** Several different parts of a web application are causing false positives with various SQL injection rules. None of the web services behind the WAF make use of SQL, so it is deemed safe to tune away these false positives by removing all the SQLi detection rules.

{{% notice warning %}}
This type of broad exclusion is dangerous and should only be considered if the rules are causing problems _and_ the application is not vulnerable to the specific attack, e.g., the PHP rules cause issues and no application behind the WAF uses PHP.

In general, the less exclusions the better, since every rule reduces the amount of bad traffic arriving at the protected application.
{{% /notice %}}

**Rule Exclusion:**

```apache
Expand All @@ -241,6 +247,11 @@ SecRuleRemoveByTag attack-sqli
SecRuleUpdateTargetById 941320 "!ARGS:wp_post"
```

{{% notice %}}
Comment thread
touchweb-vincent marked this conversation as resolved.
Outdated
If you need to use dynamic variables for optimization purposes - for example, to effectively filter Base64 variants - note that this policy supports dynamic variables, for example:
`SecRuleUpdateTargetById 1 "!TX:/^base64_ARGS:ttcsid_[\w]+$/"`
{{% /notice %}}

#### Example 4 *(SecRuleUpdateTargetByTag)*

*(Configure-time RE. Exclude specific variable from rule.)*
Expand Down Expand Up @@ -300,7 +311,7 @@ SecRule REQUEST_URI "@beginsWith /web_app_1/content" \

```apache
# CRS Rule Exclusion: 941150 - XSS Filter - Category 5: Disallowed HTML Attributes
SecRule REQUEST_URI "@beginsWith /dynamic/new_post" \
SecRule REQUEST_URI "@rx ^/dynamic/new_post" \
Copy link
Copy Markdown
Contributor

@theseion theseion Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? @beginsWith is much easier to understand.

Copy link
Copy Markdown
Contributor Author

@touchweb-vincent touchweb-vincent Nov 6, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not sure I understand your point - using ^ in a regex is just as straightforward as @beginswith, and it also provides a slightly different example. Since @beginswith is already used several times, it makes sense to vary the syntax a bit

Copy link
Copy Markdown
Contributor

@theseion theseion Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is your reasoning behind changing the operator here? @rx is harder to understand.

Copy link
Copy Markdown
Contributor Author

@touchweb-vincent touchweb-vincent Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don’t understand why you think @rx ^ is more complicated than beginsWith - and honestly, if they’re at the point of saying that, then mod_security2 is probably not the right tool for them, imo, since they’ll be writing regexes all day long just to deal with their false positives.

Copy link
Copy Markdown
Contributor

@theseion theseion Nov 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please explain why you've made this change.

Copy link
Copy Markdown
Contributor Author

@touchweb-vincent touchweb-vincent Nov 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I replaced @beginswith with @rx because it adds a concrete, real-world example of a pattern they’ll use almost every day.

Using @rx (regular expression) shows a more flexible and practical case than @beginswith, since it can handle a wider variety of inputs - something they'll frequently need in production scenarios.

In short, this change makes the rule both more instructive and more representative of what developers will actually encounter.

Copy link
Copy Markdown
Member

@EsadCetiner EsadCetiner May 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@touchweb-vincent I see where your coming from, but I think kind of information is better suited in the section about creating rules. I think we should keep the false positive tuning doc simple to avoid overloading the reader with too much information.

"id:1020,\
phase:1,\
pass,\
Expand All @@ -314,6 +325,10 @@ SecRule REQUEST_URI "@beginsWith /dynamic/new_post" \

**Scenario:** The values of request cookie 'uid' are causing false positives with various SQL injection rules when trying to log in to a web service at location '/webapp/login.html'. It is decided that it is not a risk to allow SQL-like content in this specific cookie's values for the login page, however it is deemed unacceptable to disable the SQLi detection rules for anything apart from the specific request cookie in question at the login page only. It is decided to tune away these false positives by excluding only the problematic request cookie from the SQLi detection rules, and only when accessing '/webapp/login.html'.

{{% notice warning %}}
This type of broad exclusion is dangerous. 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.
{{% /notice %}}

**Rule Exclusion:**

```apache
Expand Down
Loading