Fix ModSecurity Blocking Your Site: 403 & 406 Errors

You didn't touch a thing. No plugin update, no file edit, nothing in the error logs about permissions — and yet a form submission, a login attempt, or even just loading a specific page suddenly throws a bare "403 Forbidden" or "406 Not Acceptable." If your site loads fine everywhere else and the block only happens on certain actions (submitting a form, uploading a file, saving a post with a URL in the text), the culprit almost certainly isn't your files or their permissions. It's ModSecurity, the web application firewall running quietly underneath cPanel, deciding your legitimate request looks like an attack.

Here's how to confirm that's what's happening, find the exact rule doing it, and fix it without turning off protection for the whole account.

Symptom: How a ModSecurity Block Actually Looks

ModSecurity blocks are easy to mistake for something else because the error page itself gives you almost nothing to go on. A few patterns give it away:

• The 403 or 406 only happens on specific requests — submitting a contact form, saving a WordPress post, logging into wp-admin, uploading a plugin ZIP — while the rest of the site loads normally.
• It started right after you added content containing something that looks like code: a URL in a text field, a snippet of JSON, an email signature with special characters, or a base64 string.
• WooCommerce checkout fails at the payment step, or a REST API call from a plugin returns 403 with no useful message in the browser console.
• The error is inconsistent — it happens for some users but not others, or on some form fields but not others on the same page.

Compare that to a permissions-based 403: that one is usually site-wide, constant, and traces back to a bad chmod or a broken restore. If your block is narrow and request-specific, keep reading.

Cause: Why ModSecurity Flags Legitimate Traffic

ModSecurity works off rule sets — most cPanel servers ship with the OWASP Core Rule Set (CRS) or a vendor set like Comodo/Atomicorp. Each rule pattern-matches request data (POST bodies, query strings, headers, cookies) against signatures for SQL injection, XSS, path traversal, and so on. The problem is that legitimate content frequently looks close enough to those signatures to trip a rule:

• A contact form field containing SELECT, UNION, or -- as plain English text (not SQL) can trip an SQLi rule.
• A WordPress post body with an embedded <script> tag, an iframe embed, or even certain HTML attributes can trip an XSS rule.
• File uploads with certain MIME types or filenames containing ../-like patterns can trip path traversal rules.
• Large POST payloads (long-form pages, big REST API calls) can hit body-size or rule-scan limits and get flagged as suspicious rather than just rejected for size.
• Aggressive rule sets (particularly some Comodo/Atomicorp CRS bundles) are simply stricter out of the box than OWASP CRS, and flag a lot more false positives on CMS platforms like WordPress and WooCommerce.

None of this means your server is misconfigured. It means the firewall is doing its job a little too enthusiastically for your specific content.

Fix: Find the Rule and Whitelist It Precisely

Step 1 — Confirm it's ModSecurity and get the rule ID

In cPanel, look for ModSecurity Tools (also called "ModSecurity Audit Log" depending on your host's setup). If you have access to it:

1. Reproduce the failing action (submit the form, save the post) right before checking the log.
2. Open ModSecurity Tools and look for the most recent entry matching your domain and timestamp.
3. Note the Rule ID (a number like 981318 or 210492) and the matched pattern — this tells you exactly which check fired and why.

If cPanel doesn't expose that tool on your account, check the server's ModSecurity audit log directly (if you have SSH/root, this is usually under /usr/local/apache/logs/modsec_audit.log or similar; on managed shared hosting, ask your host to pull the last block for your domain — SkyServer support can grab this for you in minutes).

Step 2 — Whitelist the rule for that path only

Never disable ModSecurity entirely for your account just to fix one form. Instead, scope the exception as tightly as possible. In cPanel's ModSecurity Tools, most rule sets let you disable a specific rule ID for a specific domain with one click, which is the safest option. If you're doing it manually via .htaccess (only if your host allows ModSecurity directives there):

<IfModule mod_security.c>
  SecRuleRemoveById 981318
</IfModule>

To scope it even tighter to a single URL path, wrap it in a <LocationMatch> or use SecRuleUpdateTargetById to exclude just one form field (for example, a WYSIWYG content field that legitimately contains HTML) rather than turning the rule off site-wide:

SecRuleUpdateTargetById 981318 "!ARGS:content"

That tells ModSecurity to keep enforcing rule 981318 everywhere except the content POST field, which is exactly the surgical fix you want for a WYSIWYG editor or a post body.

Step 3 — If you're on WordPress, check plugin-level firewalls too

Some security plugins (Wordfence, Sucuri, All In One WP Security) run their own WAF logic in addition to server-level ModSecurity. If disabling the ModSecurity rule doesn't clear the block, check the plugin's firewall log next — you may be fighting two separate firewalls with the same symptom.

Step 4 — Test immediately, don't guess

After whitelisting, repeat the exact action that failed. Don't assume it's fixed from the rule change alone — ModSecurity rule updates sometimes need a few seconds to reload, and CDN/cache layers (Cloudflare, LiteSpeed cache) can serve a stale error page if you test too quickly.

Prevention: Keep the Firewall Without the False Positives

• Whitelist by rule ID and field, never by disabling ModSecurity outright. A blanket "just turn it off" fix removes real protection along with the annoyance.
• Check the audit log before you touch anything else. Guessing at permissions or plugin conflicts when it's actually a WAF rule wastes time and can lead to unnecessary chmod changes that create new problems.
• Re-test after every plugin or theme update. New form fields, new REST endpoints, or new HTML in the editor can trip rules that never mattered before.
• Keep a short list of your whitelisted rule IDs somewhere you'll actually find it again — a comment in .htaccess or a note in your host's ticket history. Six months from now you'll want to know why rule 981318 is disabled for your domain and not accidentally re-enable it during a migration.
• If you're moving hosts, mention which ModSecurity rules you've had to whitelist so the new server's rule set gets the same exceptions instead of you rediscovering every one of them from scratch.

Frequently Asked Questions

Is it safe to just disable ModSecurity for my whole account?

You can, but it's rarely the right call. ModSecurity blocks a huge range of automated attack traffic before it ever reaches your application. Disabling it entirely removes that layer for every request, not just the one that's currently a false positive. Scoping the fix to a single rule ID and field keeps the protection intact everywhere else.

How do I know which rule ID blocked my request if cPanel doesn't show ModSecurity Tools?

Ask your hosting provider to check the server's ModSecurity audit log for your domain around the timestamp of the failed request. On SkyServer accounts, support can pull this for you directly — you don't need root access to get the rule ID.

Why does this only happen on some form fields and not others?

ModSecurity rules typically target specific request arguments, not the whole page. A rule scanning for SQL injection patterns might only check certain POST fields, which is why a content editor field trips it while a plain text "name" field doesn't.

Could a CDN or caching plugin be showing me an old error even after I fix the rule?

Yes. If you use Cloudflare, LiteSpeed Cache, or a similar layer in front of your site, purge its cache after making the ModSecurity change and test again. A stale cached error page can look identical to a live block.

Does WooCommerce checkout failing with a 403 always mean ModSecurity?

Not always — payment gateway or SSL issues can also cause checkout failures. But if the 403 appears specifically when submitting the checkout form (rather than loading the checkout page), and the rest of the site works fine, ModSecurity is the first thing worth ruling out via the audit log.