ModSecurity Rules in cPanel: 9 FAQs [Solved]

What is ModSecurity and how does it work in cPanel?

ModSecurity is an open-source web application firewall that runs as an Apache module. It evaluates HTTP requests against a set of rules, each with a unique ID, severity rating, and pattern match. cPanel includes ModSecurity by default and loads the OWASP CRS v3 or v4 ruleset depending on your version.

Each rule checks request headers, POST body data, query strings, or uploaded files. When a match occurs, ModSecurity can block the request, log it, or both. The action depends on the rule's configuration. Most OWASP rules use the "deny" action with a 403 status code.

Rules are organized by attack category: protocol violations (920000 series), SQL injection (942000), XSS (941000), and remote file inclusion (931000). A single request can trigger multiple rules if it contains several suspicious patterns.

How do I read ModSecurity audit logs in cPanel?

The audit log sits at /usr/local/apache/logs/modsec_audit.log on most cPanel servers. SSH in and run:

Each blocked request generates a section marked with a unique ID like [07/Aug/2026:06:45:12] [unique_id]. The section contains the full HTTP request, all matched rules, and the final action taken.

Look for lines starting with "Message:" — these show which rule ID fired. A line like "[id \"942100\"]" tells you rule 942100 matched. Note that ID; you'll need it for whitelisting.

WHM also provides a graphical viewer. Navigate to Security Center > ModSecurity Tools > Hits List. Filter by domain to narrow results. The interface shows rule IDs, request URLs, and timestamps in a table format.

• tail -100 /usr/local/apache/logs/modsec_audit.log | grep -A 20 '403'
• grep 'unique_id' /usr/local/apache/logs/modsec_audit.log | tail -10

How do I whitelist a ModSecurity rule for a specific domain?

Two methods exist: WHM's ModSecurity Vendors interface and manual Apache configuration. The WHM method is safer for multi-tenant environments.

In WHM, go to Security Center > ModSecurity Vendors. Click "Edit" next to OWASP. Scroll to the domain list and select your target domain. Add the rule ID (like 942100) to the "Disable Rules" field. Save and wait 60 seconds for Apache to reload.

For manual configuration, edit the domain's Apache include file. On EasyApache 4 systems, this is usually /etc/apache2/conf.d/userdata/std/2_4/username/domain.com/*.conf. Add these lines:

After editing, run '/scripts/rebuildhttpdconf && systemctl reload httpd' to apply changes. Test the previously blocked action immediately.

• <IfModule mod_security2.c>
• SecRuleRemoveById 942100 949110
• </IfModule>

Can I use .htaccess to disable ModSecurity rules?

Yes, but only if the server administrator enabled AllowOverride for ModSecurity directives. Many hosting providers disable this for performance and security reasons.

If allowed, place this block in the domain's .htaccess file in the public_html directory:

This approach lets you control rules without SSH or WHM access. The downside: .htaccess files are processed on every request, adding slight overhead. For high-traffic sites, server-level configuration is faster.

• <IfModule mod_security2.c>
• SecRuleRemoveById 942100
• SecRuleRemoveById 949110
• </IfModule>

What are the most commonly whitelisted OWASP CRS rules?

From years of support tickets, these rule IDs generate the highest false-positive rate:

Rule 920273 fires on requests with invalid UTF-8 encoding. WordPress REST API calls sometimes trigger it. Rule 942100 detects SQL keywords in parameters; admin panels with search features hit this constantly.

Rule 949110 is an anomaly score threshold. OWASP CRS uses a scoring system: each suspicious pattern adds points, and 949110 blocks when the total exceeds five. Whitelisting 949110 alone won't help; you must disable the underlying rule that contributed to the score.

• 920273: Invalid character in request
• 942100: SQL injection attack detected via libinjection
• 941100: XSS filter - Category 1: Script tag vector
• 949110: Inbound anomaly score exceeded

Should I disable ModSecurity rules globally or per-domain?

Always prefer per-domain whitelisting. Global rule changes affect every site on the server. One customer's legitimate need to disable rule 942100 doesn't justify exposing 200 other sites to SQL injection.

I've seen servers compromised because an administrator globally disabled rules 930000-939999 (file upload checks) to fix one site's upload form. Attackers uploaded PHP shells to unrelated accounts within hours.

The only time to consider global changes: when you operate a single-tenant server and you've audited every application. Even then, document the change and set a calendar reminder to review it quarterly.

How do I test ModSecurity rule changes safely?

Set up a staging subdomain that mirrors production. Apply your whitelist changes there first. Run the blocked action again — form submission, API call, whatever triggered the original 403.

Check three things: the action completes successfully, no new errors appear in /var/log/apache2/error_log, and the ModSecurity audit log shows the request passed without blocks.

Syntax errors in SecRule directives will break Apache. Before applying changes to production, run 'apachectl configtest' after editing configuration files. If it returns "Syntax OK", you're safe to reload.

Wait 24 hours on staging. Monitor for edge cases: file uploads with different extensions, form submissions with special characters, authenticated vs. anonymous requests. Only migrate to production after confirming all variants work.

When should I actually disable ModSecurity entirely?

Short answer: almost never in production.

Disable it temporarily during emergency troubleshooting when you need to isolate whether ModSecurity is causing a site outage and you're under time pressure. The moment the incident is over, re-enable ModSecurity and whitelist the specific rules.

On development servers that sit behind a firewall with no public access, disabling ModSecurity is acceptable. The attack surface is minimal and false positives slow down testing.

For staging environments that receive real production traffic for A/B testing, keep ModSecurity enabled. Attackers scan staging subdomains just as aggressively as production.

How do I update OWASP CRS rules in cPanel?

cPanel packages OWASP CRS updates with its own releases. When you run 'yum update cpanel' or '/scripts/upcp', new rulesets install automatically if available.

Check your current CRS version in WHM under Security Center > ModSecurity Vendors. The version number appears next to "OWASP ModSecurity Core Rule Set".

Major CRS updates (v3 to v4) change rule IDs and detection logic. Your existing whitelists may become invalid. Before updating, export your current whitelist configuration from WHM. After the update, review audit logs for 72 hours and adjust whitelists as needed.

Manual CRS installation is possible but breaks cPanel's package management. Stick with the bundled version unless you're running custom rules that require a specific CRS release.