ModSecurity false positives are the price of running Atomic or OWASP rules in blocking mode. The wrong fix is to switch the WAF off for the affected domain; the right fix is to whitelist the specific rule, scope, and source — and to put the snippet somewhere that survives the next Atomic ruleset update.

This is a four-scope cheat sheet: by rule ID, by IP, per-domain, and per-directory. All snippets go in /etc/modsecurity.d/rules/custom/ (or the per-domain equivalent), which Plesk preserves across updates.

Find the rule ID

Every false positive logs to /var/log/apache2/modsec_audit.log (Debian/Ubuntu) or /var/log/httpd/modsec_audit.log (EL). The block has an H section near the end with the matched rule:

grep -B2 -A5 'id "9' /var/log/apache2/modsec_audit.log | tail -40

You want the six-digit ID after [id "..."]. For Atomic rules it is usually in the 200000-399999 range; OWASP CRS uses 9xxxxx. Confirm the request that triggered it — the A section has the URI and source IP. Do not whitelist a rule you cannot link to a specific legitimate request, or you have just punched an arbitrary hole in the WAF.

Whitelist via the Plesk UI

For one-off rules, Tools & Settings → Web Application Firewall → Custom Rules accepts a ModSecurity directive directly. Add:

SecRuleRemoveById 200006

Save, then Apply Changes. Plesk writes this to /etc/modsecurity.d/rules/custom/plesk-custom.conf and reloads Apache. The UI is fine for a handful of rules; for anything more, edit the file directly so you can version-control it.

Per-domain whitelist

For a rule that only fires on one site, scope it. Create /etc/modsecurity.d/rules/custom/example.com.conf:

<IfModule mod_security2.c>
    <LocationMatch "^/">
        SecRuleRemoveById 200006
    </LocationMatch>
</IfModule>

Then include it from the domain's Apache config via Plesk's Apache & nginx Settings → Additional directives for HTTPS:

Include /etc/modsecurity.d/rules/custom/example.com.conf

This survives Plesk reconfigurations because Plesk only rewrites the httpd.conf it owns; the included file is yours.

Per-directory whitelist

For false positives confined to one path — /wp-admin/, /api/upload, a staging directory — keep the scope tight:

<LocationMatch "^/wp-admin/admin-ajax\.php">
    SecRuleRemoveById 200006 949110 980170
</LocationMatch>

Multiple IDs space-separated. Use <LocationMatch> (regex) over <Location> (literal) when the path includes query strings or wildcards.

IP-based whitelist

To allow a single source IP to bypass a rule — typical for a monitoring service or office NAT — chain with @ipMatch:

SecRule REMOTE_ADDR "@ipMatch 203.0.113.42,198.51.100.0/24" \
    "id:1000001,phase:1,nolog,allow,ctl:ruleRemoveById=200006"

ctl:ruleRemoveById disables the rule only for that request. Custom IDs in the 1000000-1999999 range are reserved for user rules; pick one not already in use.

To bypass the WAF entirely for an IP (use sparingly):

SecRule REMOTE_ADDR "@ipMatch 203.0.113.42" \
    "id:1000002,phase:1,nolog,allow,ctl:ruleEngine=Off"

Why custom/ survives updates

Both Atomic and OWASP CRS install their rules under /etc/modsecurity.d/rules/<vendor>/ and overwrite that tree on every ruleset update. The custom/ directory is referenced from Plesk's master modsecurity.conf via:

IncludeOptional /etc/modsecurity.d/rules/custom/*.conf

Plesk does not touch custom/ during ruleset updates or panel upgrades. Keep all your overrides there. The mistake is editing rules in /etc/modsecurity.d/rules/atomic/, which the next Atomic sync silently reverts. Reload after edits:

apachectl configtest && systemctl reload apache2

If the ruleset itself is the wrong fit, compare options in ModSecurity rule sets on cPanel: OWASP vs Comodo vs Atomic. The same trade-offs apply on Plesk.

How do I find which ModSecurity rule ID blocked a request in Plesk?+

Grep /var/log/apache2/modsec_audit.log (or /var/log/httpd/modsec_audit.log on EL) for the timestamp or URI; the six-digit ID in [id "..."] is what you whitelist with SecRuleRemoveById.

Will my Plesk ModSecurity whitelist survive an Atomic ruleset update?+

Yes, as long as the rule lives under /etc/modsecurity.d/rules/custom/. Atomic and OWASP CRS only overwrite their own vendor directories on update; the custom directory is included separately and preserved.

Should I disable ModSecurity for one domain instead of whitelisting?+

No. Disabling the WAF for a domain to fix one false positive removes protection for every other rule. Whitelist the specific rule ID inside a LocationMatch block scoped to the affected path.

Can I whitelist a ModSecurity rule for one IP without disabling it globally?+

Yes. Chain SecRule REMOTE_ADDR "@ipMatch <ip-or-cidr>" with ctl:ruleRemoveById=<id>. The rule still applies to every other source.

Next steps

Compare available rule sets in ModSecurity rule sets: OWASP vs Comodo vs Atomic.
If the WAF stopped loading entirely after a Plesk upgrade, see Plesk server components not configured.
Renew or upgrade your Plesk licence — Atomic rules ship with Web Host and above.

Whitelist Plesk ModSecurity rules without breaking ruleset updates