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

content/2-how-crs-works/2-3-false-positives-and-tuning.md

@@ -221,6 +221,11 @@ 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 must be avoided at all costs for most standard web application use cases.
+In such contexts, you must never do this.
+{{% /notice %}}
+
 **Rule Exclusion:**
 
 ```apache
@@ -241,6 +246,11 @@ SecRuleRemoveByTag attack-sqli
 SecRuleUpdateTargetById 941320 "!ARGS:wp_post"
 ```
 
+{{% 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:
+`SecRuleUpdateTargetById 1 "!TX:/^base64_ARGS:ttcsid_[\w]+$/"`
+{{% /notice %}}
+
 #### Example 4 *(SecRuleUpdateTargetByTag)*
 
 *(Configure-time RE. Exclude specific variable from rule.)*
@@ -300,7 +310,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" \
     "id:1020,\
     phase:1,\
     pass,\
@@ -314,6 +324,11 @@ 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 must be avoided at all costs for most standard web application use cases.
+In such contexts, you should never do this.
+{{% /notice %}}
+
 **Rule Exclusion:**
 
 ```apache