How to Fix EasyStore Product Image Deletion 403 Errors Caused by ModSecurity

If you're running Joomla with EasyStore and OWASP ModSecurity CRS enabled, you may encounter an unexpected HTTP 403 Forbidden error when attempting to delete product images from the EasyStore administration panel.

The issue occurs because EasyStore uses an HTTP DELETE request when removing product images. Some default OWASP Core Rule Set (CRS) configurations do not permit the DELETE method, causing ModSecurity to block the request before Joomla can process it.

This tutorial explains how to identify the offending security rule and implement a targeted exception that allows EasyStore to delete product images without disabling ModSecurity or weakening security across your hosted websites.

Symptoms

You may experience the following symptoms:

• Product images cannot be deleted from EasyStore.

• The administration interface returns a 403 Forbidden error.

• Other EasyStore functions continue working normally.

• ModSecurity audit logs show blocking events.

• The browser's developer tools show failed DELETE requests.

The Apache error log may contain messages similar to:

ModSecurity: Access denied with code 403 (phase 2)

REQUEST-949-BLOCKING-EVALUATION.conf

RESPONSE-980-CORRELATION.conf

These messages indicate that ModSecurity's anomaly scoring system has blocked the request. However, they do not necessarily identify the original rule responsible for the block.

Step 1: Locate the ModSecurity Audit Log

Connect to your web server using SSH.

The location of the ModSecurity audit log depends on your operating system, web server configuration, and hosting environment.

Common locations include:

/var/log/modsec_audit.log
/var/log/apache2/modsec_audit.log
/var/log/httpd/modsec_audit.log

If you're unsure where your audit log is located, run:

sudo find /var/log -type f \( -iname '*modsec*' -o -iname '*audit*' \) 2>/dev/null

Once you locate the audit log, search for your affected domain:

sudo grep -i -B 10 -A 25 "yourdomain.com" /path/to/modsec_audit.log | tail -150

Replace yourdomain.com with your actual domain name and /path/to/modsec_audit.log with the location of your audit log.

Step 2: Identify the Offending ModSecurity Rule

When examining the audit log, look for the original rule violation.

In our investigation, we identified the following entry:

[id "911100"]
[msg "Method is not allowed by policy"]
[data "DELETE"]

The offending rule was:

REQUEST-911-METHOD-ENFORCEMENT.conf

Rule ID:

911100

The rule belongs to the OWASP Core Rule Set and enforces permitted HTTP request methods.

Why Does This Happen?

EasyStore uses an HTTP DELETE request to remove product images.

An example request generated by EasyStore looks similar to:

DELETE /easystore/administrator/index.php?option=com_easystore&task=/api.media&product_id=35&ids=464&_method=delete

The request is legitimate, but ModSecurity's default allowed-method configuration does not include DELETE. 

Consequently, ModSecurity assigns the request an anomaly score of 5.

The blocking evaluation rule then triggers:

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

The RESPONSE-980-CORRELATION.conf entry is simply reporting the accumulated security score. It is not the original cause of the problem.

Step 3: Locate the CRS Exclusion Configuration

Instead of modifying the original OWASP rule, we will create a targeted exclusion.

OWASP CRS provides a dedicated configuration file for exclusions that need to be evaluated before the core rules.

Depending on your installation, the file may be named:

REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Its location depends on how ModSecurity and OWASP CRS were installed.

Common locations include:

/etc/modsecurity/

/etc/apache2/modsecurity.d/rules/

/etc/httpd/modsecurity.d/

You can search for the configuration file using:

sudo find /etc -name 'REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf' 2>/dev/null

Before making changes, create a backup of the file.

For example:

sudo cp /path/to/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf \
/path/to/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.bak

Replace both paths with the actual location of your configuration file.

Open the file using your preferred text editor.

For example:

sudo nano /path/to/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Step 4: Add a Targeted EasyStore Exception

Add the following configuration to the bottom of the file:

# EasyStore - Allow product media deletion
# Only applies to downmadisonavenue.com
# Restricted to EasyStore's product media DELETE endpoint.

SecRule REQUEST_HEADERS:Host "@streq downmadisonavenue.com" \
    "id:1001001,phase:1,pass,nolog,chain"

    SecRule REQUEST_METHOD "@streq DELETE" \
        "t:none,chain"

    SecRule REQUEST_URI "@beginsWith /easystore/administrator/index.php" \
        "t:none,chain"

    SecRule ARGS:option "@streq com_easystore" \
        "t:none,chain"

    SecRule ARGS:task "@streq /api.media" \
        "t:none,ctl:ruleRemoveById=911100"

Important: Replace downmadisonavenue.com with your own domain.

Also ensure that the custom rule ID 1001001 is not already being used by another custom ModSecurity rule on your server.

How This Exception Works

The exception only activates when all five conditions match:

When all conditions match, ModSecurity removes rule 911100 from the current transaction. This is important because we are not disabling HTTP method enforcement globally. Other websites and applications hosted on the same server continue receiving the normal ModSecurity protections.

Step 5: Validate the Web Server Configuration

After saving the file, check your Apache configuration for syntax errors.

On Apache installations, run:

sudo apachectl configtest

On some systems, the command may instead be:

sudo httpd -t

A successful result should look like:

Syntax OK

If the configuration passes, reload Apache:

sudo systemctl reload apache2

On systems using the httpd service:

sudo systemctl reload httpd

If the configuration reports an error, do not reload until the problem has been corrected.

Note: If you are using Nginx with ModSecurity, the configuration validation and reload commands will differ. Make sure you are editing the configuration file actually loaded by your ModSecurity installation.

Step 6: Test EasyStore Product Image Deletion

Log in to your Joomla administrator panel.

Navigate to:

1. Components → EasyStore.

2. Open Products.

3. Edit a product containing multiple images.

4. Attempt to delete one of the product images.

The image should now delete successfully.

You can also inspect the ModSecurity audit log again:

sudo grep -i -B 3 -A 8 "downmadisonavenue.com" /path/to/modsec_audit.log | tail -80

You should no longer see rule 911100 blocking the matching EasyStore DELETE request.

Security Considerations

It is important not to solve ModSecurity problems by simply disabling the firewall or excluding an entire website from inspection. The approach demonstrated here is more restrictive. We are allowing one specific HTTP method for one specific application endpoint on one specific domain.

The following protections remain in place:

• OWASP Core Rule Set continues inspecting other requests.

• SQL injection protections remain enabled.

• Cross-site scripting protections remain enabled.

• Other HTTP method enforcement remains enabled.

• Other hosted domains are unaffected by this exception.

Joomla authentication, authorization, and CSRF protections must also remain enabled.

Note: This configuration addresses the specific rule violation identified in our EasyStore installation. Other installations may encounter different ModSecurity rules or use different application paths. Always inspect your own audit logs before implementing an exclusion.

Conclusion

ModSecurity is an important part of securing a web hosting environment, but occasionally legitimate application requests can trigger security rules. EasyStore's use of HTTP DELETE for product image management is one example. Rather than disabling ModSecurity or weakening server-wide protections, a targeted CRS exclusion allows the application to perform its intended operation while preserving the remaining security protections. This approach is useful for administrators running Joomla and EasyStore on a variety of hosting environments who want to maintain security without interfering with legitimate application functionality.

AGG Town Tech

Practical Technology. Real Solutions.

Website: https://agg-town-tech.com