Correct syntax for modsecurity rules for Wordpress / Elementor false positives

I'm getting tripped by my WHM ModSecurity using OWASP3 rules.

I'd like to create a custom rule to the Rules List in Home>Security Center > ModSecurity Tools>Rules List following these exclusions:

    <locationmatch "/wp-admin/admin-ajax.php">
    SecRuleRemoveById 300013
    SecRuleRemoveById 300015
    SecRuleRemoveById 300016
    SecRuleRemoveById 300017
    SecRuleRemoveById 949110
    SecRuleRemoveById 980130
</locationmatch>

<locationmatch "/wp-admin/page.php">
    SecRuleRemoveById 300013
    SecRuleRemoveById 300015
    SecRuleRemoveById 300016
    SecRuleRemoveById 300017
    SecRuleRemoveById 949110
    SecRuleRemoveById 980130
</locationmatch>

<locationmatch "/wp-admin/post.php">
    SecRuleRemoveById 300013
    SecRuleRemoveById 300015
    SecRuleRemoveById 300016
    SecRuleRemoveById 300017
    SecRuleRemoveById 949110
    SecRuleRemoveById 980130
</locationmatch>

I am unsure of how to frame this using the modsec rules syntax 'SecRule / phase, etc'

Any advice welcomed.

*** UPDATE Here are the triggered items from ModSecurity HitList

921110: HTTP Request Smuggling Attack Request: POST /wp-admin/post.php Action Description: Warning. Justification: Pattern match "(?:get|post|head|options|connect|put|delete|trace|track|patch|propfind|propatch|mkcol|copy|move|lock|unlock)\s+(?:\/|\w)[^\s]*(?:\s+http\/\d|[\r\n])" at ARGS:content.

941100: XSS Attack Detected via libinjection Request: POST /wp-admin/post.php Action Description: Warning. Justification: detected XSS using libinjection.

941160: NoScript XSS InjectionChecker: HTML Injection Request: POST /wp-admin/admin-ajax.php Action Description: Warning. Justification: Pattern match "(?i:(?:<\w[\s\S]*[\s\/]|'"?)(?:on(?:d(?:e(?:vice(?:(?:orienta|mo)tion|proximity|found|light)|livery(?:success|error)|activate)|r(?:ag(?:e(?:n(?:ter|d)|xit)|(?:gestur|leav)e|start|drop|over)|op)|i(?:s(?:c(?:hargingtimechange ..." at ARGS:actions.

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/concepts/false_positives_tuning/