How to Fix Roundcube Webmail 403 Errors Caused by ModSecurity in Plesk

If you manage a Plesk server running multiple websites and email accounts, you may eventually encounter an issue where Roundcube webmail suddenly returns a 403 Forbidden error. In our case, users could access the webmail login page, but clicking certain folders, opening messages, or navigating through Roundcube caused ModSecurity to block the request. The problem wasn't Roundcube, Postfix, or Dovecot. It was a false positive generated by the OWASP Core Rule Set (CRS) running under ModSecurity.

This tutorial explains how to identify the problem and implement a targeted fix without disabling ModSecurity.

1. Understanding the Problem

The affected webmail installations included:

• webmail.downmadisonavenue.com

• webmail.agg-town-tech.com

When navigating through Roundcube, Apache's error log showed messages similar to:

ModSecurity: Warning. Pattern match at REQUEST_HEADERS:Referer.

[id "932239"]

[msg "Remote Command Execution:
Unix Command Injection found in user-agent or referer header"]

The request was being flagged because the Referer header contained a normal Roundcube URL:

https://webmail.agg-town-tech.com/roundcube/?_task=mail&_mbox=INBOX.Sent

The CRS rule incorrectly interpreted part of the URL as a potential command-injection attempt. The next rule, 949110, evaluated the anomaly score and blocked the request:

ModSecurity: Access denied with code 403 (phase 2).

[id "949110"]

[msg "Inbound Anomaly Score Exceeded (Total Score: 5)"]

This confirmed that ModSecurity was responsible for the 403 response.

2. Identify the ModSecurity Rule

The two important rule IDs were:

Rule 932239 generated a false positive because it inspected the Referer header. Rather than disabling either rule globally, we needed to tell ModSecurity to ignore only the Referer header when evaluating rule 932239 for Roundcube requests.

3. Locate the Correct ModSecurity Configuration File

On our Plesk server, the correct location for this exception was:

/etc/apache2/modsecurity.d/rules/owasp_modsecurity_crs_4-plesk/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

This file is important because it is processed before the OWASP Core Rule Set rules. Adding an exclusion here allows ModSecurity to apply the exception before rule 932239 evaluates the request.

Important: Adding the exception to a configuration file loaded after the CRS rules may not work as intended.

4. Back Up the Configuration

Before making changes, create a backup:

sudo cp -a \
/etc/apache2/modsecurity.d/rules/owasp_modsecurity_crs_4-plesk/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf \
/etc/apache2/modsecurity.d/rules/owasp_modsecurity_crs_4-plesk/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.backup

This lets you restore the original configuration if something goes wrong.

5. Add the Roundcube ModSecurity Exception

Initially, we used individual exceptions for each affected hostname.

For example, the Down Madison Avenue exception was:

SecRule REQUEST_HEADERS:Referer "@rx ^https?://webmail\.downmadisonavenue\.com/" \
    "id:1001001,phase:1,pass,nolog,ctl:ruleRemoveTargetById=932239;REQUEST_HEADERS:Referer"

The AGG Town Tech exception was:

SecRule REQUEST_HEADERS:Referer "@rx ^https?://webmail\.agg-town-tech\.com/" \
    "id:1001004,phase:1,pass,nolog,ctl:ruleRemoveTargetById=932239;REQUEST_HEADERS:Referer"

Both exceptions worked, but maintaining a separate rule for every domain would become inconvenient as additional websites and email domains were added.

A Better Solution: One Global Roundcube Exception

For a server hosting multiple domains, we can use a single hostname-independent exception:

# Roundcube global false-positive exception.
# Exclude Referer from CRS rule 932239 for all Roundcube requests.
SecRule REQUEST_URI "@beginsWith /roundcube/" \
    "id:1001005,phase:1,pass,nolog,ctl:ruleRemoveTargetById=932239;REQUEST_HEADERS:Referer"

This rule applies to requests whose URI begins with /roundcube/, regardless of the hostname. It eliminates the need to add another exception every time a new domain is configured.

Important: This global rule is the proposed consolidated configuration. Before enabling it, remove the two hostname-specific exceptions to avoid redundant rules. Keep unrelated custom exceptions in the file.

6. Validate the Apache Configuration

After saving the changes, run:

sudo apache2ctl configtest

You should receive:

Syntax OK

If Apache reports an error, correct it before proceeding.

7. Reload Apache

Once the configuration passes validation, reload Apache:

sudo systemctl reload apache2

A reload applies the configuration changes without requiring a full server reboot.

8. Test Roundcube Webmail

Open the webmail address for each affected domain.

Test the following:

1. Log in to Roundcube.

2. Open the Inbox.

3. Open the Sent folder.

4. Open an individual email.

5. Send a test email.

6. Verify that incoming email is received.

Also inspect the Apache error log:

sudo grep -E '932239|949110' /var/log/apache2/error.log | tail -20

Look for new entries associated with your Roundcube requests.

9. Why This Fix Is Better Than Disabling ModSecurity

One possible workaround would be to disable ModSecurity for the entire webmail installation or turn off rule 932239 globally.

Neither is recommended.

Our approach is more targeted:

• ModSecurity remains enabled.

• OWASP CRS protections remain active.

• Rule 932239 continues inspecting other request data.

• Only the Referer header is excluded from that particular rule.

• Other security rules continue operating normally.

• The global exception can cover existing and future Roundcube installations.

This preserves the majority of the server's existing web application firewall protection.

Conclusion

The Roundcube 403 problem was caused by a false positive in OWASP CRS rule 932239. The solution was to create a targeted ModSecurity exclusion in the CRS pre-exclusion configuration file. We first implemented individual exceptions for Down Madison Avenue and AGG Town Tech, verified that users could access Roundcube, and successfully tested sending and receiving email. For a multi-domain Plesk server, consolidating these exceptions into one global Roundcube rule is a cleaner long-term approach.

The key takeaway: When ModSecurity blocks legitimate application traffic, identify the exact rule responsible and create a narrowly scoped exception instead of disabling the firewall.