ModSecurity False Positives – Diagnosing and Fixing

ModSecurity is the Web Application Firewall (WAF) running on iWebVault servers. It blocks SQL injection attempts, XSS payloads, scanner probes, and other attacks. Sometimes it also blocks completely legitimate requests — your WordPress admin save fails with 403, your plugin update breaks, your contact form submission disappears. These are false positives. This guide covers diagnosing what rule fired, finding the offender, and creating exceptions without disabling protection wholesale.

Signs of a ModSecurity false positive

• Action that worked yesterday now returns 403 Forbidden.
• WordPress admin save fails with “You don’t have permission” or 403.
• Form submission silently fails or shows 403.
• Plugin update breaks with 403 in middle of process.
• Specific content with certain words (often technical/security keywords) can’t be saved.

If a request returns 200 OK (success) but functionality is broken, ModSecurity probably isn’t the cause — different problem.

Finding the rule that fired

Via cPanel

1. cPanel → Security → ModSecurity Tools.
2. Click “Hits List” to see recent ModSecurity events.
3. Recent blocks show rule ID, the part of the request that triggered, and severity.

Each entry shows:

• Date/time.
• Rule ID (number like 933100).
• Rule message describing what was detected.
• URI of the blocked request.
• The matched data.

Match it against what you were doing — usually obvious.

Via SSH (if available)

tail -100 /usr/local/apache/logs/error_log | grep -i modsec

Shows recent ModSecurity events with full context. Look for “ModSecurity: Access denied” entries.

Audit log (most detailed)

tail -1000 /usr/local/apache/logs/modsec_audit.log

Full request and response details. Shows headers, body, exactly what matched.

Common false positive patterns

Rule 949110 — “Inbound Anomaly Score Exceeded”

Aggregate score from multiple rules pushed the request over threshold. Each individual rule had low confidence but combined exceeded limit.

Often when posting content with multiple “suspicious” elements (SQL-like words, HTML in body, etc.).

Rule 920350 — “Host header is a numeric IP address”

You accessed site directly by IP instead of domain. Sometimes triggers during testing.

Rule 941100 / 941110 — XSS attack

Detected HTML/JS in request body. Common for:

• WordPress posts with code snippets.
• Documentation sites with examples.
• Forms with HTML field content.

Rule 942100 / 942110 — SQL injection

SQL-like keywords in request. Common when:

• Posting articles about databases.
• WHMCS or similar admin saving database-related fields.
• Custom forms with SQL keywords legitimately in content.

Rule 920272 / 920273 — Invalid characters

Non-ASCII or special characters in URL. Multi-language sites hit this.

Fix 1: Whitelist a single rule for one location

Best practice: disable specific rule for specific URL, not entire site.

Add to .htaccess in your site root:

<IfModule mod_security2.c>
    SecRuleRemoveById 941100 942100
</IfModule>

Disables rules 941100 and 942100 for the entire site. Better targeted to specific paths:

<LocationMatch "/wp-admin/post.php">
    SecRuleRemoveById 941100 942100
</LocationMatch>

LocationMatch in .htaccess may not work depending on server config; sometimes need a server-level rule via support ticket.

Fix 2: Disable ModSecurity for specific domain via cPanel

1. cPanel → Security → ModSecurity.
2. Find your domain in the list.
3. Toggle to “OFF” for that domain.
4. Save.

Disables ALL ModSecurity protection for that domain. Last resort — site loses WAF protection.

Fix 3: Specific rule disabled per domain via cPanel

1. cPanel → Security → ModSecurity → “Disable Rule” tab.
2. Enter the rule ID from the hits list.
3. Select your domain.
4. Save.

cPanel manages exceptions properly without editing .htaccess. Preferred method.

Fix 4: Request server-level whitelist

If cPanel-level fixes aren’t enough or you need a broader exception:

1. Submit support ticket.
2. Include: rule IDs being triggered, URLs affected, what action triggers them.
3. Request: whitelist rules for your specific domain or path.
4. Support evaluates and may apply server-level exception.

Faster than fighting cPanel UI for complex cases.

When NOT to whitelist

• You’re not sure it’s a false positive. Verify the action is legitimate before whitelisting.
• The rule fires for many unrelated requests. Suggests broader misuse or attack, not bug.
• You’re tempted to disable many rules. Step back — site may have deeper issue.

Triage workflow

1. Reproduce the issue. Verify it consistently fails the same way.
2. Check ModSecurity hits list immediately after. See if a rule fired during your reproduction.
3. Note rule ID and the matched data.
4. Decide if it’s false positive. Is the request actually legitimate?
5. Apply minimal whitelist. Specific rule for specific path or domain.
6. Verify fix works. Reproduce action — should succeed now.
7. Document. Note which rules you disabled and why.

Common questions

“My site got blocked at random — but I don’t see anything in ModSecurity logs.” Check CSF temp bans, CPGuard logs, or Imunify360 events. ModSecurity is one of several security layers.

“WordPress update fails halfway. ModSecurity?” Often yes — large file uploads of plugin/theme code can trip XSS rules. Whitelist for /wp-admin/update.php and similar paths.

“Should I just disable ModSecurity entirely?” No — that loses real protection. Targeted exceptions for false positives only.

“Same rule fires repeatedly for legitimate users.” Solid signal it’s mis-tuned for your application. Whitelist that rule for your site; report to ModSecurity upstream as candidate refinement.

“How do I see ModSecurity events as they happen?” SSH: tail -f /usr/local/apache/logs/modsec_audit.log

“My visitor IP is being blocked by ModSecurity — how do I unblock myself?” ModSecurity blocks requests, not IPs. If you’re getting consistent 403, the rule is firing on your specific request pattern. Not a temp IP ban.

What’s next

• Other security layers: Imunify360, CSF firewall.
• cPanel error logs: Error logs guide.
• WordPress hardening: Hardening.

ModSecurity false positives are normal — security rules can’t be perfect for every site’s content. The skill is identifying the rule quickly, applying targeted exceptions, and keeping notes so you don’t whitelist the same rule twice. Done well, ModSecurity stays effective against attacks while your legitimate work doesn’t get blocked.