ModSecurity rule sets on cPanel: OWASP CRS vs Comodo cWAF

Enabling ModSecurity in WHM is one click. Picking the right rule set is the decision that actually determines whether your customers file 200 false-positive tickets next week or whether their stolen credit-card form quietly relays for a month before anyone notices.

cPanel ships ModSecurity v3 with EasyApache 4 and exposes four vendor rule sets in Security Center → ModSecurity Vendors. The choice between them is the only WAF decision most cPanel operators ever make, and the defaults are not the right answer for a shared-hosting workload. This is the comparison, written for someone deciding between them this afternoon.

The four choices in WHM

Every fresh WHM install lists these four vendors. You can run more than one simultaneously, but every additional rule set multiplies your false-positive surface — so in practice operators pick one primary and occasionally bolt on a second for a narrow purpose.

The two interesting axes are false-positive rate (which determines your support ticket load) and custom application coverage (which determines whether a hand-rolled PHP app gets any protection at all). The rest is fairly even.

OWASP CRS: best generic protection, worst out of the box

The OWASP Core Rule Set is the reference ModSecurity ruleset. It is generic by design — its rules trigger on SQL injection patterns, command injection, path traversal, RFI, and similar attack classes regardless of the application underneath. That is exactly what you want if a customer is running a bespoke PHP CRM you have never heard of. It is exactly what you do not want as default protection for 800 stock WordPress sites.

CRS uses anomaly scoring: each matching rule adds a score, and the request is blocked only when the total crosses a threshold (default 5 for inbound, 4 for outbound). This is smarter than the "first match blocks" model used by Comodo and Atomicorp — three rules each scoring 2 will block where any one of them alone would not.

The big lever is paranoia level. CRS ships four (PL1 through PL4):

• PL1 — production-safe on most servers. Catches SQLi/XSS/RCE with low false positives.
• PL2 — tighter regexes. Starts blocking legitimate WYSIWYG editor input.
• PL3 — paranoid. Blocks routine WordPress admin saves, Elementor, WooCommerce checkout.
• PL4 — research-grade. Will block the WHM interface itself if you proxy it.

The cPanel ModSecurity Vendor page does not expose paranoia level — you set it by editing the bundled crs-setup.conf after enabling the vendor:

# CRS config location after enabling the vendor in WHM
/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/crs-setup.conf

Find SecAction "id:900000,phase:1,nolog,pass,t:none,setvar:tx.blocking_paranoia_level=1" and adjust the integer. PL1 is the only sane default for shared hosting; bump individual accounts to PL2 only if you understand the false-positive profile.

CRS's other weakness on cPanel: rule updates are not automatic. cPanel bundles a CRS snapshot and refreshes it on EasyApache updates — roughly monthly. The upstream project ships rules more often than that. If you need same-day CVE coverage, OWASP CRS via the EA4 channel is not your tool.

Comodo cWAF: low ticket load, weak custom-app coverage

The Comodo Web Application Firewall (now Sectigo cWAF, though the WHM label still says Comodo) is the rule set most cPanel operators end up running by default — it has been bundled and enabled by cPanel's installer in various versions. It is fundamentally different from OWASP CRS in two ways:

1. Application-specific rules. Comodo ships rule groups for WordPress, Joomla, Magento, Drupal, vBulletin, and a handful of others. These rules know what a legitimate wp-admin request looks like and only block deviations from it. False positives on stock CMS workloads are dramatically lower than CRS at any paranoia level.
2. First-match blocking, no anomaly scoring. A single matching rule blocks the request. This makes the rule set easier to reason about and easier to whitelist per-rule-ID, but it also means rules have to be conservative — Comodo cannot stack three weak signals into a confident block.

The tradeoffs are real. Comodo's coverage of custom or obscure applications is poor — a hand-rolled PHP form will get the generic SQLi/XSS rules but not much more. Update cadence is slow (quarterly at best, sometimes longer). And the rule set is opaque: there is no published changelog comparable to the OWASP CRS GitHub repo.

For a shared cPanel server where 90 % of traffic is WordPress and the customer support budget is the binding constraint, Comodo is usually the right call. For a server hosting a single bespoke SaaS, it is the wrong one.

Atomicorp Basic and Advanced: weekly updates, registration friction

Atomicorp's free Atomic Secured Linux (ASL) Basic rules sit between OWASP CRS and Comodo. The free tier requires registration on the Atomicorp site to pull a license key, which is friction worth mentioning — it means you cannot redeploy a server from configuration management without provisioning the license out of band.

The Advanced tier is paid and adds more rules, faster updates, and Atomicorp's signature work on shellshock-class vulnerabilities. In 2026 the practical reason to pay for Atomicorp Advanced over Imunify360 is rare — Imunify gives you a managed WAF plus a malware scanner and IDS for similar money. Most operators evaluate both and pick Imunify360.

Imunify360 WAF: when free rule sets are not enough

Imunify360's WAF component replaces cPanel's ModSecurity vendor entirely. It is the right choice when you have outgrown the operational cost of tuning free rule sets — typically around 500+ accounts or when a recurring class of attack (credential stuffing, automated WordPress login probing) is generating more support work than the licence costs.

The differences that matter:

• AI greylist. Suspicious-but-not-confirmed requests get a CAPTCHA challenge instead of a block. This eliminates a large share of the false-positive tickets you would file against a hand-tuned CRS install.
• Centralised tuning. Imunify pushes rule updates daily from CloudLinux's central reputation database. You get same-day coverage for zero-days like the nginx Rift CVE without an EA4 update.
• Per-account whitelist via UI. Customers can self-serve their own false positives from the cPanel plugin. Every minute of support not spent on SecRuleRemoveById is a win.

The trade is cost (roughly $12/mo/server at the Single plan, with volume discounts) and the loss of fine-grained control — Imunify's rule engine is largely a black box compared to CRS. For the operators it suits, this is a feature, not a bug. The Imunify360 install guide walks the deployment.

Recommended config by workload

Switching between rule sets

You can disable and switch vendors freely in Security Center → ModSecurity Vendors without restarting Apache:

# CLI equivalent — useful in configuration management
whmapi1 modsec_disable_vendor vendor_id=OWASP3
whmapi1 modsec_enable_vendor url=https://waf.comodo.com/cpanel/comodo_litemod_apache.yaml

The disabled vendor's rule files stay on disk under /etc/apache2/conf.d/modsec_vendor_configs/ — if you want them gone, run whmapi1 modsec_remove_vendor vendor_id=<id>. Watch /etc/apache2/logs/modsec_audit.log for the first 24 hours after a switch: rule sets disagree about what counts as suspicious, and the audit log will tell you which legitimate requests you are about to break.

Tuning false positives

Whichever rule set you pick, you will end up whitelisting rule IDs. The mechanics are the same across vendors. To disable a single rule globally:

# In /etc/apache2/conf.d/modsec2.user.conf
SecRuleRemoveById 949110

To disable a rule for one virtual host only, drop it inside a <LocationMatch> in the account's user config. WHM exposes the same control under ModSecurity Tools → Hits List → Disable Rule, which is fine for one-off whitelisting but does not survive EasyApache updates if the rule belongs to a vendor file — always whitelist into modsec2.user.conf.

Common offenders on a WordPress-heavy server:

• 949110 — anomaly score threshold (CRS). Raise the threshold rather than disable.
• 941100 — XSS attack detected (CRS PL1). Triggers on Gutenberg block JSON.
• 200002 — Comodo's rule against eval() in POST bodies. Triggers on Elementor saves.
• 200003 — Comodo's WordPress XML-RPC rule. Disable if you actually use Jetpack.

For the broader picture of how ModSecurity sits next to the other security layers on a cPanel server, see the PHP handlers comparison and the Imunify360 install guide. For licence pricing across the stack, the cPanel license tiers breakdown lays out where ModSecurity-related limits sit in each plan.

Next steps

• Install Imunify360 on cPanel — the deployment path if free rule sets have outgrown your support budget.
• cPanel license tiers explained — Imunify360 licence sizing maps to your cPanel account-count tier.
• PHP handlers on cPanel compared — handler choice changes which user runs PHP, which changes what ModSecurity sees in the audit log.