How to Enable ModSecurity in cPanel (WAF Setup Guide)

Overview

ModSecurity (often written as mod_security) is an open-source web application firewall (WAF) that runs inside Apache. When enabled through cPanel or WHM, it inspects every incoming HTTP request and blocks anything that matches a known attack pattern — SQL injection attempts, cross-site scripting, malicious file uploads, and more.

Most cPanel servers have ModSecurity installed but not fully configured. You might be here because your host flagged suspicious traffic, a plugin triggered a 403 error, or you’re simply hardening a new account before going live. All three are valid reasons to be in this article.

If you’re on our Shared Hosting plans, ModSecurity is enabled at the server level by default — but you can still manage it per-domain from your cPanel account. VPS and dedicated server customers have full WHM access to control rule sets globally.

Prerequisites

• Active cPanel account (version 11.110 or later recommended)
• Apache with mod_security2 installed on the server (your host handles this — check with support if unsure)
• WHM root or reseller access if you want to manage rules server-wide
• Basic familiarity with your cPanel dashboard
• If you’re testing rule changes: a staging environment or a maintenance window, because aggressive rules can break legitimate site functionality

Step-by-Step: Enabling ModSecurity in cPanel

Step 1 — Log in to cPanel

Navigate to your cPanel login URL. This is typically:

https://yourdomain.com:2083
# or
https://yourserverIP:2083

Enter your username and password. If you’re unsure of your login details, check your original welcome email from Host & Tech or contact support.

Step 2 — Find the ModSecurity Section

Inside cPanel, scroll down to the Security section. Click ModSecurity. You’ll see a list of all domains and subdomains associated with your account, each with an On/Off toggle.

📝 Note: If you don’t see a ModSecurity option in the Security section, the module isn’t installed on your server. On shared hosting, this is controlled by the host — open a support ticket and ask for it to be enabled. On a VPS or dedicated server, you’d install it via WHM (covered below).

Step 3 — Enable ModSecurity for Your Domain

Click the toggle next to the domain you want to protect. It switches from Off to On immediately — there’s no save button. cPanel writes the configuration change live.

⚠ Warning: Enabling ModSecurity on a production site with no prior testing can cause false positives that block real users. If your site uses complex form submissions, a REST API, or a page builder like Elementor, I’d recommend enabling it first on a staging subdomain and watching the error logs for 24-48 hours before rolling it out to the live domain.

Step 4 — (WHM Only) Install and Configure a Rule Set

ModSecurity without rules is just an empty framework — the rules are what actually block attacks. If you have WHM access, here’s how to set up a rule set.

Log in to WHM at https://yourserverIP:2087, then navigate to Security Center > ModSecurity Vendors.

You’ll see options to add rule vendors. The two most common are:

• OWASP Core Rule Set (CRS) — free, community-maintained, very comprehensive. This is what I’d recommend starting with.
• Comodo WAF Rules — also free via WHM’s built-in vendor list, but can be more aggressive out of the box.

To add OWASP CRS manually via the command line on your server:

# Navigate to ModSecurity rules directory
cd /etc/apache2/conf.d/modsec_vendor_configs/

# Clone the OWASP CRS repo
git clone https://github.com/coreruleset/coreruleset.git owasp-crs

# Copy the default config
cp owasp-crs/crs-setup.conf.example owasp-crs/crs-setup.conf

# Restart Apache to apply
systemctl restart httpd

📝 Note: On cPanel/WHM servers running EasyApache 4, the Apache service is usually managed via httpd, not apache2. If systemctl restart httpd fails, try service httpd restart.

Step 5 — Set ModSecurity to Detection Mode First

This is the step most people skip, and it causes real problems. ModSecurity has two modes:

• Detection Only — logs rule matches but doesn’t block anything
• Prevention (active enforcement) — blocks requests that match rules

In WHM, go to Security Center > ModSecurity Configuration and set Audit Log to enabled and Rule Engine to DetectionOnly initially. After reviewing logs for a day or two, switch to On.

To set this directly in the config file:

# Edit the main ModSecurity config
nano /etc/apache2/conf.d/modsec2.conf

# Find this line and change it:
SecRuleEngine DetectionOnly

# Once you're satisfied with the logs, change to:
SecRuleEngine On

Save the file and restart Apache after any manual config change.

Step 6 — Review ModSecurity Logs

Audit logs are stored in:

/var/log/modsec_audit.log

To watch it live while testing your site:

tail -f /var/log/modsec_audit.log

Each blocked or flagged request will show the rule ID, the matched pattern, and the request URI. This is how you identify false positives before they affect real users.

Step 7 — Whitelist a Rule Causing False Positives

If a specific rule is blocking legitimate traffic (common with contact forms or WooCommerce checkout), you can disable that rule for a specific domain without turning off ModSecurity entirely.

In cPanel, go to ModSecurity > Domains, click Rules List for the affected domain, find the rule ID from your audit log, and click Disable.

To do this at the server level via WHM or config file, add a rule exception:

# Add to your custom rules file, e.g. /etc/apache2/conf.d/modsec2.user.conf
# Replace 949110 with the actual rule ID from your audit log
SecRuleRemoveById 949110

⚠ Warning: Don’t disable rules blindly. Each rule ID maps to a specific attack vector. Look up the rule ID in the OWASP CRS documentation before disabling it — some rules are critical.

Common Issues & Troubleshooting

403 Forbidden After Enabling ModSecurity

Cause: A ModSecurity rule matched something in your page’s request — often a form field value, a URL parameter, or a cookie. This is extremely common with WordPress contact forms, WooCommerce, and REST API calls.

Fix: Check /var/log/modsec_audit.log or the Apache error log at /var/log/apache2/error.log for the specific rule ID. Then whitelist that rule for the affected domain as shown in Step 7. Don’t just turn ModSecurity off entirely — that defeats the purpose.

ModSecurity Toggle Is Missing in cPanel

Cause: mod_security2 isn’t installed in EasyApache 4, or it’s installed but the cPanel feature isn’t enabled for your account.

Fix: If you’re a WHM admin, go to EasyApache 4, search for mod_security2, and install it. Then check Feature Manager to make sure ModSecurity is enabled for the relevant feature list. If you’re on shared hosting, contact support — you can’t install Apache modules yourself.

Site Loads Fine But API Calls Return 403

Cause: ModSecurity is blocking POST requests with JSON bodies or unusual headers, which is common with headless WordPress setups, React/Vue frontends, or mobile apps hitting a REST endpoint.

Fix: This is almost always OWASP CRS rule 920420 (invalid content type) or rules in the 949xxx range. Review the audit log for the exact rule. You may need to add a location-specific exception:

# In your VirtualHost config or .htaccess (if AllowOverride is on)
<Location "/wp-json/">
  SecRuleEngine Off
</Location>

📝 Note: Turning off the rule engine for /wp-json/ entirely is a quick fix but not ideal for production. Prefer disabling the specific offending rule ID instead.

ModSecurity Is On But Attacks Still Getting Through

Cause: The rule engine is set to DetectionOnly — it logs but doesn’t block. Or the rule set is outdated and doesn’t cover newer attack signatures.

Fix: Confirm your rule engine mode in /etc/apache2/conf.d/modsec2.conf. If you’re using OWASP CRS, update it:

cd /etc/apache2/conf.d/modsec_vendor_configs/owasp-crs
git pull origin main
systemctl restart httpd

cPanel Shows ModSecurity as Enabled But Apache Isn’t Enforcing It

Cause: A syntax error in a custom rules file is causing Apache to skip the ModSecurity config entirely. This happens silently — Apache still starts, but ignores the broken include.

Fix: Test your Apache config before restarting:

apachectl -t
# or
httpd -t

Fix any reported syntax errors in your custom rule files, then restart Apache. This is one of those issues where the official cPanel docs won’t tell you to check this — but it’s the actual cause about 30% of the time.

FAQ