Correct syntax for modsecurity rules for Wordpress / Elementor false positives

Core Rule Set Dev on Duty here. As the list of exclusions you gave comes from someone else's blog post it's probably best to ignore them. They disable some key functionality of the Core Rule Set (the 9xxxxx rules you're using is the OWASP Core Rule Set) so it's best not to apply those rule exclusions unless you're certain you know what you're doing and why those exclusions are required.

The three entries from the "HitList" that you quoted: are you certain those are the result of known good traffic? Are those definitely from when you were trying to update a page and you got 403 errors? If you're sure those are genuine false positives (and not attacks) then let's continue…

False positive #1

• The rule causing the false positive: 921110
• The location in question: /wp-admin/post.php
• The variable causing the false positive: ARGS:content

Applying a rule exclusion means poking a hole in your WAF's security. We want to try and be as specific as possible so that we make only the smallest hole necessary. We just want to let through the transactions that are being blocked in error and nothing more. We don't want to open a large hole and present an opportunity for attackers to get through.

With that in mind, let's try taking the following approach: let's exclude only the variable in question (ARGS:content) and exclude it only from the rule causing the issue (921110) and only for the location we've seen the problem occur at (/wp-admin/post.php).

Putting all that together looks like so:

SecRule REQUEST_URI "@beginsWith /wp-admin/post.php" \
    "id:1000,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveTargetById=921110;ARGS:content"

False positive #2

• The rule causing the false positive: 941100
• The location in question: /wp-admin/post.php
• The variable causing the false positive: Unknown

We don't know what variable is causing the issue here.

You can simply disable rule 941100 entirely for location /wp-admin/post.php, but that might be overkill (remember the smallest hole possible that we're trying to make?)

You probably want to check your logs again to find out which variable was causing you an issue with rule 941100.

False positive #3

• The rule causing the false positive: 941160
• The location in question: /wp-admin/admin-ajax.php
• The variable causing the false positive: ARGS:actions

Following the same recipe as before:

SecRule REQUEST_URI "@beginsWith /wp-admin/admin-ajax.php" \
    "id:1010,\
    phase:1,\
    pass,\
    nolog,\
    ctl:ruleRemoveTargetById=941160;ARGS:actions"

More information

For much more information on rule exclusions and tonnes of examples you can use and adapt for yourself, take a look at our excellent documentation here: https://coreruleset.org/docs/configuring/false_positives_tuning/