Introduction

ModSecurity is a web application firewall (WAF) that protects your site by filtering suspicious HTTP requests. However, it can block legitimate requests (false positives). This guide explains how to identify the cause of a block, locate the offending rule (Rule ID) and apply a targeted fix — disable a specific rule, create a domain exception, or whitelist an IP — without disabling ModSecurity globally.

In short Collect the blocked URL, the exact timestamp, the client IP and a screenshot of the error message; check cPanel → Metrics → Errors and, if you have WHM, use ModSecurity Tools → Hits List to find the Rule ID.Always prefer a targeted exception rather than replacing or disabling the WAF globally.

Prerequisites

  • cPanel access (shared hosting) or WHM/SSH (VPS/dedicated, administrator access).
  • Exact URL and time (ISO/W3C format) of the blocked request; screenshot of the error message (e.g. 403).
  • Client IP address (your IP if testing), HTTP method (GET/POST) and User-Agent if possible.

Before you begin — security principle

Never disable ModSecurity globally in production. The objective is to identify the exact rule and apply a targeted workaround: disable a specific rule, create a domain exception, or whitelist an IP. If you are not an administrator, provide all evidence to technical support.

Step-by-step procedure

If you only have a cPanel account (shared hosting)

  1. Reproduce and collect the information.

    Open the blocked page, copy the full URL, note the exact time (e.g. 2026-10-17T15:32:08Z), the displayed HTTP code (often 403), and take a screenshot of the message.

  2. Check the ModSecurity tool in cPanel.

    If your host has exposed the tool, look for Security → ModSecurity in cPanel. You can enable/disable it there temporarily to test, but reactivate it immediately after testing.

  3. Check Apache errors (cPanel).

    In cPanel, open Metrics (or Performance) → Errors to see the latest lines of the error log related to your domain; this can sometimes identify the rule or reason for the block.

  4. If the cause isn't apparent.

    Open a ticket with your hosting provider and attach: the URL, time (ISO), client IP, a screenshot and a description. Explicitly request that they check the ModSecurity hits / the modsec_audit.log for the request in question.

If you are a WHM administrator (VPS / dedicated)

  1. Open ModSecurity Tools → Hits List.

    WHM → Security Center → ModSecurity Tools → Hits List. The Hits List displays recent events; click an entry to view the Rule ID, the message, the URI, the client IP and any score.

  2. Identify the rule (Rule ID) and the action.

    Note the Rule ID and the type of action (log, pass, block). These details determine the remediation: disable the rule, create an exception, or report a false positive to the ruleset vendor.

  3. Apply a targeted fix.

    Avoid SecRuleEngine Off. Prefer:

    • disable the specific rule (by Rule ID);
    • or create an exception limited to the domain or the affected IP.

    Be careful with "vendor" rules: their management may be automated by the vendor and any modification must be documented.

Logs: where to look (common locations)

Paths vary depending on the server configuration. Common locations:

  • /usr/local/apache/logs/modsec_audit.log
  • /var/log/apache2/modsec_audit.log or per-user directories /etc/apache2/logs/modsec_audit/USERNAME

Search for the same time or the same unique_id as the error and note the Rule ID and the Action (log/pass/block).

Useful commands (advanced — root/SSH access)

# suivre les dernières lignes du log d'audit
sudo tail -f /usr/local/apache/logs/modsec_audit.log

# rechercher une IP précise ou une URL
sudo grep -n '203.0.113.45' /usr/local/apache/logs/modsec_audit.log | less
sudo grep -n '/chemin/qui/pose/probleme' /usr/local/apache/logs/modsec_audit.log | less

Diagnostic mode: audit & 'Detection Only'

To diagnose without blocking, temporarily switch the engine to 'Detection Only' (WHM → Security Center → ModSecurity Configuration) or increase the audit level. Warning: the 'log all transactions' level logs all traffic (including private data) and can quickly fill the disk. Use it only for short-term debugging and monitor disk space.

Escalation procedure — what to provide to support

Always include:

  • Full URL and time (ISO format, timezone);
  • screenshot of the error message;
  • HTTP method (GET/POST) and form fields if POST;
  • client IP and User‑Agent;
  • excerpt of the Apache/ModSecurity log around the same time (if accessible);
  • context (update, installed plugin, recent change).

Example message (copy/paste):

Objet : Blocage ModSecurity — demande d’analyse

Bonjour,

Mon site example.com subit des 403 lors d’un POST vers /chemin-exemple le 2026-10-17T15:32:08Z depuis l’IP 203.0.113.45.
Pouvez‑vous :
 - vérifier les hits ModSecurity / modsec_audit.log autour de cette date/heure ;
 - indiquer le Rule ID et le message associé ;
 - proposer une action (exception par domaine, règle à désactiver pour l’user, ou autre).

PJ : capture d’écran et URL.

Merci.

Common cases & quick fixes

  • Empty Hits List Check that the audit log is enabled (Audit Log Level). If not, ask support to enable logging.
  • Audit log too large Reduce the audit level temporarily after diagnosis and configure log rotation.
  • WordPress plugin blocked Identify the rule and create a targeted exception rather than disabling ModSecurity for the entire domain.
  • POST requests blocked Check the size and content of the request body; identify the rule and create a targeted exception.

Limitations and best practices

  • Do not remove a vendor rule without understanding the impact; prefer a local exception.
  • Keep logs during diagnosis and enable rotation (logrotate) to avoid running out of disk space.
  • Never include passwords or tokens in a support ticket; redact or mask sensitive data in log excerpts.

Official resources

Useful internal articles

Need help interpreting a log excerpt or preparing the ticket? Paste the excerpt here (mask sensitive data) and we’ll help you analyze it.

Reference documentation

  • ModSecurity® Tools | cPanel & WHM Documentation
  • ModSecurity® Configuration | cPanel & WHM Documentation
  • The cPanel & WHM Log Files | cPanel & WHM Documentation

Documentation consulted on October 17, 2026. Tools may vary depending on your hosting.