cPanel ModSecurity Rule Exclusions for REST APIs & Webhooks: Fixing 403 Forbidden in Pakistan

Configure granular ModSecurity rule exclusions in cPanel to prevent 403 Forbidden false positives on WooCommerce, Stripe, and JazzCash payment webhooks.

cPanel ModSecurity Rule Exclusions for REST APIs & Webhooks: Fixing 403 Forbidden in Pakistan

E-commerce businesses and SaaS applications hosted on cPanel servers in Pakistan routinely encounter a critical failure mode: checkout orders succeed on the client front-end, but inventory never updates, payment statuses remain “Pending”, and automated order fulfillment stalls completely.

When inspecting gateway delivery logs from payment aggregators like JazzCash, EasyPaisa, Stripe, PayFast, or Shopify, the server reveals a stream of 403 Forbidden rejection notices.

The culprit is almost always ModSecurity (OWASP Core Rule Set / CRS).

While the OWASP CRS provides vital zero-day defense against SQL injection, cross-site scripting (XSS), and remote code execution, its default inspection rules were designed for traditional HTML form POST submissions.

Modern REST APIs and automated webhooks pass nested JSON objects, base64-encoded HMAC signatures, cryptographic nonces, and unquoted serialization tokens. To ModSecurity’s rigid regex engines, an encoded webhook payload looks indistinguishable from a dangerous evasion attack, triggering Rule 949110 (Inbound Anomaly Score Exceeded) and terminating the connection immediately.

In this sysadmin masterclass, we examine how to audit /var/log/apache2/modsec_audit.log, write surgical ModSecurity rule exclusions without disabling your global WAF, and whitelist local Pakistani fintech webhooks on high-performance Dedicated Servers in Pakistan.


1. Anatomy of a Webhook False Positive

When a payment provider like JazzCash or Stripe transmits a transaction webhook to your endpoint:

POST /wp-json/wc/v3/jazzcash-ipn HTTP/1.1
Host: yourstore.pk
User-Agent: JazzCash-Webhook-Agent/2.0
Content-Type: application/json
X-Signature: c8f4b1...base64...hash==

{"pp_TxnRefNo":"T202610041830","pp_Amount":"1450000","pp_ResponseCode":"000","pp_SecureHash":"a89f..."}

ModSecurity evaluates this incoming stream through sequential phases:

  1. Rule 920420 (Request Content-Type Not Allowed): Flags non-standard application headers.
  2. Rule 941100 (XSS Filter - Script Tag / Vector Probe): Base64 hash strings containing characters like = or / frequently trigger generic XSS patterns.
  3. Rule 942100 (SQLi Filter - Detects SQL Comments/Keywords): Transaction references containing hyphens or tokens matching IS, OR, SELECT, or WAITFOR trip SQLi heuristics.
  4. Rule 949110 (Anomaly Score Terminate): When the cumulative score exceeds 5 (default blocking limit), ModSecurity returns an Apache 403 Forbidden error.

2. Inspecting the ModSecurity Audit Log

Before disabling any rules, you must identify the exact Rule ID and offending parameter from the audit log:

# Search ModSecurity audit log for recent 403 blocks on REST endpoints
tail -n 500 /var/log/apache2/modsec_audit.log | grep -E "wp-json|403" -A 10 -B 5

A typical offending block entry looks like this:

--b7a9c1f0-H--
Message: Access denied with code 403 (phase 2). 
Pattern match "(?i)(?:<script[^>]*>|javascript:|alert\\()" at ARGS:pp_SecureHash. 
[file "/etc/apache2/conf.d/modsec_vendor_configs/OWASP3/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] 
[line "182"] 
[id "941100"] 
[msg "XSS Filter - Category 1: Script Tag Vector"] 
[severity "CRITICAL"] 
[tag "application-multi"] 
Action: Intercepted (evaluating anomaly score)

Here, Rule ID 941100 is falsely triggering on the parameter pp_SecureHash.


3. Surgical Rule Exclusions in cPanel / WHM

Never disable ModSecurity globally for the entire website. That leaves your WordPress admin dashboard and PHP login scripts defenseless. Instead, configure targeted rule exclusions using SecRuleUpdateTargetById or ctl:ruleRemoveById.

To whitelist rules cleanly across the entire server or a specific virtual host, edit /etc/apache2/conf.d/modsec/modsec2.user.conf:

# /etc/apache2/conf.d/modsec/modsec2.user.conf

<IfModule mod_security2.c>
    # -------------------------------------------------------------
    # Exclude False Positive Rule 941100 & 942100 for WooCommerce REST API
    # -------------------------------------------------------------
    <LocationMatch "^/wp-json/wc/v[0-9]+/(?:orders|webhooks|payment-callback)">
        # Remove specific rule IDs ONLY for this URI path
        SecRuleRemoveById 941100 942100 920420 920272
    </LocationMatch>

    # -------------------------------------------------------------
    # Whitelist Verified JazzCash & EasyPaisa IP Gateways
    # -------------------------------------------------------------
    # If the request originates from trusted payment IP ranges,
    # bypass rule engine completely for the callback endpoint:
    SecRule REMOTE_ADDR "@ipMatch 202.163.110.0/24,175.107.20.0/24" \
        "id:100001,\
        phase:1,\
        pass,\
        nolog,\
        ctl:ruleEngine=Off"
</IfModule>

After modifying the file, always verify the Apache syntax before restarting:

# Verify Apache configuration syntax
apachectl configtest

# If Syntax OK, rebuild and restart
/scripts/restartsrv_apache

4. Account-Level Whitelisting via .htaccess (LiteSpeed / ModSec v2)

If you are a reseller or end-user without root WHM access running LiteSpeed Enterprise or Apache with SecRuleEngine user overrides enabled:

# Add to /home/username/public_html/.htaccess
<IfModule mod_security2.c>
    # Bypass inspection on the specific IPN webhook URL
    SecRule REQUEST_URI "@beginsWith /wp-json/jazzcash/v1/ipn" \
        "id:200001,phase:2,pass,nolog,ctl:ruleRemoveById=941100,ctl:ruleRemoveById=942100,ctl:ruleRemoveById=949110"
</IfModule>

For advanced defense rules on standard WordPress endpoints, review our master tutorial on cPanel Custom ModSecurity Rules WordPress.


5. Handling Massive Webhook Spikes on Bare Metal

During peak flash sales (such as 11.11 or Blessed Friday in Pakistan), your store may receive 500+ concurrent payment webhooks per second. On underpowered VPS nodes, each incoming webhook forces ModSecurity to parse multi-megabyte regex rules, choking CPU cores and crashing Apache.

Deploying on bare-metal Dedicated Servers provides unshared CPU L3 cache and NVMe I/O throughput to process regex inspection in microseconds. Furthermore, if you manage high outbound transactional mail alerts following successful checkouts, optimize your mail queue using our cPanel Exim Retry Queue & Spool Tuning architecture.


ENTERPRISE E-COMMERCE SECURITY

High-Performance cPanel Hosting with Zero False Positives

Protect your online store without breaking payment webhooks. NextGen Cloud provides hardened cPanel environments with fine-tuned ModSecurity rules and unthrottled bare-metal performance in Pakistan.