Top 50 ModSecurity Exceptions and Security Auditing Plugins for Apache for Independent Web Developers and Indie Hackers

Leveraging ModSecurity for Indie E-commerce: Beyond Default Rulesets

For independent web developers and indie hackers building e-commerce platforms on Apache, robust security is not a luxury but a fundamental requirement. While commercial WAFs offer managed solutions, understanding and fine-tuning ModSecurity provides a powerful, cost-effective, and highly customizable defense. This post dives into practical ModSecurity exceptions and auditing techniques essential for securing your bespoke e-commerce stack, moving beyond generic advice to actionable configurations.

Common E-commerce ModSecurity False Positives and Their Exceptions

The default ModSecurity Core Rule Set (CRS) is aggressive by design. For dynamic e-commerce applications, certain legitimate user behaviors or application-specific parameters can trigger false positives. Identifying and creating precise exceptions is crucial to avoid blocking genuine customers.

1. AJAX Requests and API Endpoints

Modern e-commerce sites heavily rely on AJAX for dynamic content loading, cart updates, and checkout processes. These often involve POST requests with complex JSON payloads or specific headers that might resemble malicious patterns. If your application uses a specific API endpoint, like /api/v1/cart/update, and it consistently triggers a rule (e.g., rule ID 942100 for SQL injection attempts), you can create an exception.

Example: Exception for a specific AJAX endpoint (e.g., blocking rule 942100 for POST to /api/v1/cart/update)

SecRuleEngine On

# Add this rule *before* the CRS rules are loaded, or in a dedicated
# exceptions file that is included early.
SecRule REQUEST_URI "@streq /api/v1/cart/update" "id:1000001,phase:1,log,pass,ctl:ruleRemoveById=942100"

# Include your CRS rules here
# Include /etc/modsecurity-crs/crs-setup.conf
# Include /etc/modsecurity-crs/rules/*.conf

Explanation:

• SecRuleEngine On: Ensures ModSecurity is active.
• id:1000001: A unique ID for your custom rule. It’s good practice to use IDs above 1000000 for custom rules to avoid conflicts with CRS.
• phase:1: The rule is evaluated during the request headers phase.
• log: Logs the event.
• pass: Allows the request to proceed without further inspection by subsequent rules that would have otherwise blocked it.
• ctl:ruleRemoveById=942100: This is the core of the exception. It tells ModSecurity to disable rule ID 942100 specifically for requests matching the preceding condition.
• "@streq /api/v1/cart/update": Matches requests where the URI is exactly /api/v1/cart/update. Use @ அமில for case-insensitive string matching if needed.

2. Custom URL Parameters and Query Strings

E-commerce platforms often use unique URL parameters for tracking, filtering, or internal logic. For instance, a parameter like product_variant_id or a custom UTM parameter might trigger rules related to argument injection. If you’ve identified that product_variant_id is safe for your application and is causing false positives (e.g., rule ID 942200 for XSS), you can exclude it.

Example: Excluding a specific parameter from all rules

SecRuleEngine On

# Exclude 'product_variant_id' from all ModSecurity checks
SecRule ARGS "product_variant_id" "id:1000002,phase:2,log,pass,ctl:ruleRemoveTargetById=942200;942300"

# Include your CRS rules here
# Include /etc/modsecurity-crs/crs-setup.conf
# Include /etc/modsecurity-crs/rules/*.conf

Explanation:

• id:1000002: Custom rule ID.
• phase:2: Rule evaluated during the request body phase.
• ctl:ruleRemoveTargetById=942200;942300: This directive removes the specified rule IDs (942200 and 942300 in this example) from inspecting the matched argument. You can list multiple rule IDs separated by semicolons.
• ARGS "product_variant_id": Matches any argument whose name is exactly product_variant_id. This applies to both GET and POST parameters.

Advanced: Excluding a parameter only for a specific URL path

SecRuleEngine On

# Exclude 'product_variant_id' only for requests to /products/details.php
SecRule REQUEST_URI "@streq /products/details.php" "id:1000003,phase:1,log,pass,chain"
    SecRule ARGS "product_variant_id" "ctl:ruleRemoveTargetById=942200;942300"

# Include your CRS rules here
# Include /etc/modsecurity-crs/crs-setup.conf
# Include /etc/modsecurity-crs/rules/*.conf

Explanation:

• The chain directive allows subsequent rules to be evaluated only if the preceding rule matches. This ensures the parameter exclusion is context-specific to the URL.

3. User-Generated Content (Reviews, Comments)

User reviews and comments are prime targets for XSS and injection attacks. However, legitimate user input can sometimes contain characters or patterns that trigger ModSecurity. If you have a dedicated endpoint for submitting reviews (e.g., /submit_review.php) and you’ve thoroughly sanitized input on the application side, you might need to relax certain rules for the comment/review body field.

Example: Relaxing XSS rules for a specific form field in a specific context

SecRuleEngine On

# Target rule 941100 (XSS) for the 'review_text' field when submitting to /submit_review.php
SecRule REQUEST_URI "@streq /submit_review.php" "id:1000004,phase:1,log,pass,chain"
    SecRule REQUEST_HEADERS:Content-Type "@streq application/x-www-form-urlencoded" "chain"
        SecRule ARGS:review_text "@rx .*" "ctl:ruleRemoveById=941100"

# Include your CRS rules here
# Include /etc/modsecurity-crs/crs-setup.conf
# Include /etc/modsecurity-crs/rules/*.conf

Explanation:

• This example is more granular. It targets rule 941100 (a common XSS detection rule) specifically for the review_text argument, but only when the request is a POST to /submit_review.php and the content type is URL-encoded form data.
• @rx .* is a regex that matches any non-empty string, effectively applying the rule removal to any value provided for review_text in this context.

4. Specific HTTP Headers

Some applications or third-party integrations might use custom HTTP headers that could be misinterpreted by ModSecurity. For instance, a header like X-My-App-Token might trigger rules related to unusual headers.

Example: Excluding a custom header from inspection

SecRuleEngine On

# Exclude the custom header 'X-My-App-Token' from all rules
SecRule REQUEST_HEADERS:X-My-App-Token "@rx .*" "id:1000005,phase:1,log,pass,ctl:ruleRemoveById=981200"

# Include your CRS rules here
# Include /etc/modsecurity-crs/crs-setup.conf
# Include /etc/modsecurity-crs/rules/*.conf

Explanation:

• REQUEST_HEADERS:X-My-App-Token: Matches the specific header.
• ctl:ruleRemoveById=981200: Disables rule 981200 (a hypothetical rule for anomalous headers) for this specific header. You’ll need to identify the actual rule ID causing the false positive.

5. File Uploads and Specific MIME Types

While ModSecurity is excellent at detecting malicious file uploads, legitimate but unusual file types or specific upload scenarios might require exceptions. For example, if you allow users to upload custom SVG icons that contain embedded scripts (which you’ve vetted), you might need to adjust rules.

Example: Allowing specific SVG content for a trusted user role (requires application logic integration)

SecRuleEngine On

# This is a conceptual example. Real-world implementation often requires
# application-level checks for user roles and content validation.
# Assuming rule 920350 (Anomalous Uploaded File) is triggered by valid SVGs.

# If user is authenticated and has role 'designer' (requires custom variable set by app)
SecRule &TX:USER_ROLE "@streq designer" "id:1000006,phase:1,log,pass,chain,ctl:ruleRemoveById=920350"
    # And if the uploaded file is an SVG
    SecRule FILES:upload_icon "@endsWith .svg" "chain"
        # And if the file content is deemed safe by application logic (not directly ModSecurity)
        # This part is tricky and often relies on application-level checks.
        # For simplicity, we'll just remove the rule for SVG uploads by designers.
        # A more robust solution might involve a custom ModSecurity script or Lua module.
        SecRule REQUEST_URI "@streq /upload_asset.php" "log,pass"

# Include your CRS rules here
# Include /etc/modsecurity-crs/crs-setup.conf
# Include /etc/modsecurity-crs/rules/*.conf

Explanation:

• This example demonstrates a more complex scenario where an exception is conditional on a custom variable (TX:USER_ROLE) set by the application and the file extension.
• FILES:upload_icon refers to the uploaded file named upload_icon.
• @endsWith .svg checks the file extension.
• ctl:ruleRemoveById=920350 disables the rule for these specific conditions.
• Important Note: Relying solely on ModSecurity for complex content validation within file uploads is risky. Application-level sanitization and validation are paramount. This example illustrates how ModSecurity *can* be integrated with application logic, but it’s not a substitute for secure coding practices.

Top 50 ModSecurity Rules to Consider for Exceptions (and Why)

Instead of a rigid list of 50, it’s more effective to understand *categories* of rules that commonly cause false positives in e-commerce and require careful consideration. The specific rule IDs will vary slightly between CRS versions (v2.x vs. v3.x), but the principles remain the same. Always consult the CRS documentation for the exact IDs relevant to your version.

Category 1: Input Validation & Sanitization (Rules 941xxx, 942xxx)

These rules detect common injection patterns like SQL injection, XSS, command injection, and LDAP injection. False positives often arise from:

• Legitimate data containing special characters: Usernames, product descriptions, or search queries with characters like <, >, ', ", ;.
• Complex application-specific parameters: Parameters used for internal logic or tracking that might resemble malicious payloads.
• API payloads: JSON or XML data with nested structures or specific keywords.

Common Rule IDs to Review (CRS v3.x examples):

• 941100: Generic XSS Attack (e.g., <script>)
• 941110: XSS Attack – Script Tag (e.g., <script>)
• 941120: XSS Attack – onerror (e.g., onerror=...)
• 942100: SQL Injection Attack: Common Comment Sequence
• 942200: SQL Injection Attack: Found common character combination
• 942300: SQL Injection Attack: Found character combination
• 942400: SQL Injection Attack: Found SQL character
• 942500: SQL Injection Attack: Found SQL keyword
• 942900: SQL Injection Attack: Found numeric value
• 949100: Command Injection: Unix Shell Argument
• 949200: Command Injection: Unix Shell Command
• 950001: LDAP Injection Attempt

Category 2: File Uploads & Malicious Content (Rules 920xxx, 930xxx)

These rules focus on preventing the upload of malicious files (executables, scripts) and detecting suspicious content within allowed file types.

• False positives: Unusual but legitimate file types, or files with metadata that triggers signature-based detection.

Common Rule IDs to Review (CRS v3.x examples):

• 920100: Uploaded File – Executable
• 920110: Uploaded File – Script
• 920120: Uploaded File – Web Shell
• 920350: Uploaded File – Anomalous Uploaded File
• 930100: Multipart Form Boundary – Invalid
• 932100: File Upload – Invalid Content-Type

Category 3: Protocol Enforcement & Anomaly Detection (Rules 951xxx, 952xxx, 980xxx)

These rules enforce HTTP protocol standards and detect unusual or malformed requests.

• False positives: Non-standard but functional client behavior, aggressive crawlers, or specific proxy/load balancer configurations.

Common Rule IDs to Review (CRS v3.x examples):

• 951000: HTTP Protocol Violation: Malformed Header
• 951001: HTTP Protocol Violation: Invalid Character
• 951002: HTTP Protocol Violation: Invalid Chunk Encoding
• 951003: HTTP Protocol Violation: Invalid Request Line
• 952000: HTTP Protocol Violation: Invalid Host Header
• 981100: Anomaly Score Exceeded (this is a meta-rule, often requires tuning of underlying rules)
• 981200: Anomaly Score Too High (similar to 981100)

Category 4: Application-Specific Attacks (Rules 960xxx, 970xxx)

These rules target vulnerabilities specific to certain applications or technologies (e.g., PHP, WordPress, specific CMS). For custom e-commerce platforms, these might be less relevant unless you’re using common frameworks.

• False positives: Application logic that uses patterns similar to known exploits.

Common Rule IDs to Review (CRS v3.x examples):

• 960001: PHP Injection Attack
• 960002: PHP Injection Attack: File Inclusion
• 970001: Session Fixation Attempt

Security Auditing and Log Analysis for ModSecurity

Effective ModSecurity management hinges on robust auditing. Without understanding *why* a rule is firing, you risk creating overly permissive exceptions that weaken your security posture.

1. Configuring ModSecurity Audit Logs

Ensure ModSecurity is configured to log relevant information. The audit log is crucial for diagnosing false positives.

Example: Apache Configuration Snippet

# In your Apache httpd.conf or a dedicated modsecurity.conf file
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:500|4xx)$"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log

# For CRS v3.x, you might also want to log anomaly scores
SecAction "id:1000007,phase:1,log,pass,setenv:ANOMALY_SCORE=0"
SecAction "id:1000008,phase:3,log,pass,setenv:ANOMALY_SCORE_EXTENDED=%{TX.0}"
SecAction "id:1000009,phase:4,log,pass,setenv:ANOMALY_SCORE_FINAL=%{TX.1}"

Explanation:

• SecAuditEngine RelevantOnly: Logs transactions that trigger ModSecurity rules or result in specific HTTP status codes.
• SecAuditLogRelevantStatus "^(?:500|4xx)$": Further refines logging to only include transactions with 4xx or 5xx status codes.
• SecAuditLogParts ABIJDEFHZ: Specifies which parts of the transaction to log (A=Request Headers, B=Request Body, I=Intermediary, J=JSON Request Body, D=Debug Data, E=Error Log, F=Response Headers, H=Response Body, Z=Transaction End). Adjust as needed.
• SecAuditLogType Serial: Logs each transaction to a single file.
• SecAuditLog: Path to the audit log file. Ensure Apache has write permissions.
• The SecAction rules are for capturing anomaly scores, which are invaluable for tuning.

2. Analyzing Audit Logs with `modsec-audit-viewer.pl`

The Perl script `modsec-audit-viewer.pl` (often included with ModSecurity or available in repositories) is essential for parsing and understanding the audit logs.

Example: Viewing logs for a specific rule ID

perl /path/to/modsec-audit-viewer.pl --log /var/log/apache2/modsec_audit.log --ruleid 941100

Example: Viewing logs for a specific IP address

perl /path/to/modsec-audit-viewer.pl --log /var/log/apache2/modsec_audit.log --ip 192.168.1.100

Example: Viewing logs for a specific URL

perl /path/to/modsec-audit-viewer.pl --log /var/log/apache2/modsec_audit.log --url "/api/v1/cart/update"

Explanation:

• The viewer script parses the complex audit log format and presents relevant transactions in a more readable way.
• Use these commands to pinpoint transactions that triggered false positives. Examine the logged request details (headers, body, matched variables) to understand the context.

3. Using Anomaly Scoring for Tuning

Instead of disabling rules outright, ModSecurity CRS v3.x heavily relies on anomaly scoring. Each rule contributes to a score, and the transaction is blocked if the score exceeds a certain threshold (e.g., 5 for anomaly scoring, 10 for paranoia level 1). Tuning involves adjusting the scores of individual rules or the overall threshold.

Example: Reducing the anomaly score contribution of a specific rule

SecRuleEngine On

# Reduce the anomaly score for rule 941100 (XSS) to 1 (default is often 5)
SecRuleUpdateActionById 941100 "log,auditlog,msg:'XSS Attack',id:'941100',phase:1,t:none,block,score:1"

# Include your CRS rules here
# Include /etc/modsecurity-crs/crs-setup.conf
# Include /etc/modsecurity-crs/rules/*.conf

Explanation:

• SecRuleUpdateActionById: A directive to modify the actions of an existing rule.
• score:1: Sets the anomaly score contribution of this rule to 1. This makes it less likely to trigger a block on its own, but it still contributes to the overall score.
• This is often preferable to `ruleRemoveById` as it maintains some level of detection.

Best Practices for ModSecurity Exceptions

• Least Privilege: Only create exceptions that are absolutely necessary. Avoid broad exceptions.
• Specificity: Target exceptions to specific URLs, parameters, HTTP methods, or even user roles (if your application supports it).
• Documentation: Comment every custom rule, explaining *why* the exception was made, the rule ID it affects, and when it was implemented.
• Regular Review: Periodically review your custom exceptions. As your application evolves, some exceptions may become obsolete or even dangerous.
• Test Thoroughly: After implementing exceptions, rigorously test your application, especially the areas where exceptions were made, to ensure functionality and security. Use penetration testing tools or services.
• Version Control: Store your ModSecurity configuration, including custom rules and exceptions, in a version control system (like Git).
• Separate Files: Keep custom rules and exceptions in separate files (e.g., `local_rules.conf`, `custom_exceptions.conf`) and include them in your main Apache configuration. This simplifies management and upgrades.

Conclusion

For independent web developers and indie hackers, mastering ModSecurity is a significant advantage. By understanding common false positives, implementing precise exceptions, and diligently auditing logs, you can build a highly effective and customized Web Application Firewall for your e-commerce platform. Remember that ModSecurity is a tool; its effectiveness depends on informed configuration and continuous vigilance.