Skip to content

Troubleshooting Elementor 403 Errors: ModSecurity Configuration Guide

• By Jasper Frumau

The Problem

Recently, I encountered a frustrating issue where Elementor was throwing 403 Forbidden errors seemingly out of nowhere. Users couldn’t access the Elementor editor, and the WordPress admin would randomly block certain actions. Initially, I suspected plugin conflicts, theme issues, or even server misconfigurations, but the real culprit turned out to be much more specific.

After some investigation, I discovered that Apache’s ModSecurity module was overzealously blocking legitimate Elementor requests. ModSecurity is a powerful web application firewall (WAF) that helps protect websites from various attacks, but sometimes its rules can be too aggressive and block normal functionality.

Understanding the Issue

Elementor, like many modern page builders, uses AJAX requests and dynamic content loading extensively. These requests can sometimes trigger ModSecurity rules designed to prevent PHP code injection and other security threats. The problem becomes particularly apparent when:

  • Loading the Elementor editor interface
  • Saving page layouts or widgets
  • Using dynamic content features
  • Working with custom CSS or JavaScript within Elementor

The key to solving this was diving into the Apache error logs to understand exactly which ModSecurity rules were being triggered and why.

Analyzing the Error Logs

When I checked the Apache error logs, I found clear evidence of ModSecurity blocking legitimate Elementor requests. Here’s what the logs revealed:

2023-09-12 06:01:35	Error	xxxx:xxxx:1001:f8dc:ec06:c64e:c4c5:9f49		[client xxxx:xxxx:1001:f8dc:ec06:c64e:c4c5:9f49] ModSecurity: Access denied with code 403 (phase 4). Pattern match "(?:\\\\b(?:call_user_func|f(?:get(?:c|s{0,1}s)|open|read|scanf|tp_(?:nb_){0,1}f{0,1}(?:ge|pu)t|write)|gz(?:compress|open|read|(?:encod|writ)e)|move_uploaded_file|read(?:dir|(?:gz){0,1}file)|s(?:candir|ession_start)|(?:bz|proc_)open)|\\\\$_(?:session|(?:ge| ..." at RESPONSE_BODY. [file "/etc/httpd/conf/modsecurity.d/rules/comodo_free/16_Outgoing_FilterPHP.conf"] [line "17"] [id "214620"] [rev "1"] [msg "COMODO WAF: PHP source code leakage||staging.domain.nl|F|3"] [data "Matched Data: call_user_func found within RESPONSE_BODY: <!DOCTYPE html>\\x0d\\x0a<html lang=\\x22nl-NL\\x22>\\x0d\\x0a<head>\\x0d\\x0a<meta charset=\\x22UTF-8\\x22>\\x0d\\x0a<meta name=\\x22viewport\\x22 content=\\x22width=device-width, initial-scale=1\\x22>\\x0d\\x0a<link rel=\\x22profile\\x22 href=\\x22https://gmpg.org/xfn/11\\x22>\\x0d\\x0a\\x0d\\x0a<title>FPD products &#8211; domain</title>\\x0a<meta name='robots' content='noindex, nofollow' />\\x0a<link rel='dns-prefetch' href='//stats.wp.com' />\\x0a<lin [hostname "staging.domain.nl"] [uri "/index.php"] [unique_id "ZP-intSbLAZgSve2kf6qCgAAAM8"], referer: https://staging.domain.nl/wp-admin/admin.php?page=elementor-app&ver=3.15.3				Apache error
2023-09-12 06:01:35	Error	xxxx:xxxx:1001:f8dc:ec06:c64e:c4c5:9f49		[client xxxx:xxxx:1001:f8dc:ec06:c4c5:9f49] ModSecurity: Warning. Operator GE matched 4 at TX:outgoing_points. [file "/etc/httpd/conf/modsecurity.d/rules/comodo_free/20_Outgoing_FiltersEnd.conf"] [line "38"] [id "214940"] [rev "2"] [msg "COMODO WAF: Outbound Points Exceeded| Total Points: 4|staging.domain.nl|F|2"] [severity "CRITICAL"] [tag "CWAF"] [tag "FiltersEnd"] [hostname "staging.domain.nl"] [uri "/index.php"] [unique_id "ZP-intSbLAZgSve2kf6qCgAAAM8"], referer: https://staging.domain.nl/wp-admin/admin.php?page=elementor-app&ver=3.15.3

Breaking Down the Log Entries

The error logs revealed two specific issues:

  1. Rule ID 214620: This rule flagged “PHP source code leakage” because it detected the string call_user_func in the response body. This is a legitimate PHP function that Elementor uses for various operations, but the WAF mistakenly identified it as a potential security threat.
  2. Rule ID 214940: This rule triggered when the total “outgoing points” exceeded the threshold (4 points in this case). ModSecurity uses a scoring system where different suspicious patterns add points, and when the total exceeds a certain threshold, it blocks the request.

Both rules were part of the COMODO WAF ruleset, which is commonly used with Plesk hosting environments.

The Solution: Excluding ModSecurity Rules

The fix involved adding these specific rule IDs to the Web Application Firewall exclusion list in Plesk. Here’s how to do it:

Step 1: Access Plesk WAF Settings

  1. Log into your Plesk control panel
  2. Navigate to Websites & Domains
  3. Select your domain
  4. Click on Web Application Firewall (ModSecurity)

Step 2: Add Rule Exclusions

  1. Look for the Rule Exclusions or Disabled Rules section
  2. Add the following rule IDs to exclude them:
    • 214620 (PHP source code leakage detection)
    • 214940 (Outgoing points threshold)

Step 3: Apply and Test

  1. Save the configuration
  2. Test Elementor functionality to ensure the 403 errors are resolved
  3. Monitor the error logs to confirm no new related issues

Alternative Solutions

If you don’t have access to Plesk or prefer other approaches, consider these alternatives:

1. Custom ModSecurity Rules

You can create custom rules to whitelist Elementor-specific requests by adding them to your ModSecurity configuration:

# Whitelist Elementor admin requests
SecRule REQUEST_URI "@contains /wp-admin/admin.php" \
    "id:999001,phase:1,pass,ctl:ruleRemoveById=214620,ctl:ruleRemoveById=214940"

2. .htaccess Modifications

For specific pages or directories, you can disable ModSecurity entirely:

<IfModule mod_security.c>
    SecFilterEngine Off
    SecFilterScanPOST Off
</IfModule>

3. Server-Level Configuration

Contact your hosting provider to adjust ModSecurity settings at the server level if you’re experiencing widespread issues.

Prevention and Best Practices

To avoid similar issues in the future:

  1. Regular Log Monitoring: Check your error logs regularly, especially after plugin updates or new installations
  2. Staging Environment Testing: Always test changes on a staging site first to catch ModSecurity conflicts early
  3. Documentation: Keep track of any WAF exclusions you’ve made for future reference
  4. Balanced Security: Don’t disable ModSecurity entirely; instead, fine-tune specific rules to maintain security while allowing legitimate functionality

Conclusion

ModSecurity conflicts with WordPress plugins like Elementor are more common than you might think. The key is understanding how to read the error logs and identify which specific rules are causing problems. By carefully excluding only the necessary rules rather than disabling the entire WAF, you can maintain both security and functionality.

Remember that every exclusion you make potentially reduces your site’s security, so only exclude rules that you’ve confirmed are causing legitimate functionality issues. When in doubt, consult with your hosting provider or a security professional to ensure you’re making the right decisions for your specific environment.

Comments are closed for this post.