docs: add rfdos warning

content/_index.md

@@ -23,7 +23,7 @@ The project endeavors not to make breaking changes in **minor releases** (i.e.,
 
 New functionality and breaking changes are made in **major releases** (i.e., 3.3).
 
-For information about what has changed in recent versions of the software, refer to the project's [CHANGES](https://github.com/coreruleset/coreruleset/blob/v4.0/dev/CHANGES.md) file on GitHub.
+For information about what has changed in recent versions of the software, refer to the project's [CHANGES](https://github.com/coreruleset/coreruleset/blob/main/CHANGES.md) file on GitHub.
 
 ## Documentation Source
 

content/deployment/install.md

@@ -94,6 +94,16 @@ Other aspects of ModSecurity, particularly engine-specific parameters, are contr
 
 In many scenarios, the default example CRS configuration will be a good enough starting point. It is, however, a good idea to take the time to look through the example configuration file *before* deploying it to make sure it's right for a given environment.
 
+{{% notice warning %}}
+In particular, _Response_ rules are enabled by default. You must be aware that you may be vulnerable to RFDoS attacks, depending on the responses your application is sending back to the client. You could be vulnerable, if your responses from your application can contain user input. If an attacker can submit user input that is returned as part of a response, the attacker can craft the input in such a way that the response rules of the WAF will block responses containing that input _for all_ clients. For example, a blog post might no longer be accessible because of the contents of a comment on the post. See [this blog post](https://blog.sicuranext.com/response-filter-denial-of-service-a-new-way-to-shutdown-a-website/) about the problems you could face.
+There is an [experimental scanner](https://github.com/edoardottt/RFDos-Scanner) that uses [nuclei](https://github.com/projectdiscovery/nuclei?tab=readme-ov-file#install-nuclei) to find out if are affected. So if
+you are unsure, first test your application before enabling the response rules, or risk accidentally blocking some valid responses.
+Response rules can be easily disabled by uncommenting the rule with id `900500` in the `crs-setup.conf` file,
+since CRS version 4.10.0.
+
+**The CRS team believes that the damage that can be caused by webshells and information leakage outweighs the damage of RFDos attacks, in general. Thus, the response rules remain active in the default configuration for now.**
+{{% /notice %}}
+
 Once any settings have been changed within the example configuration file, as needed, it should be renamed to remove the .example portion, like so:
 
 ```bash