403 Forbidden errors when working on your website? Firewalls, firewalls, firewalls

Description of Issue

You’ll get a 403 forbidden error when there’s a file permissions issue, or when our web application firewall is blocking your request. This could be due to what it think is malicious content in the file you’re requesting, or it could be thinking the data you’re submitting to the server is malicious.

This can happen seemingly out of the blue because of firewall rules are updated on a weekly basis; potentially adding new rules each week that could have an effect on the operation of your site. Note that the rules are most likely to affect submitting data to the server, like when submitting a form or updating data in the backend of your site.

Find Error in Logs

The first step is to check the server logs to find out why it’s providing such an error.

  • Log in to Plesk
  • Under “Websites and Domains”, click “Logs” for the domain
  • In the “Type” dropdown (the second from the left) un-check “access”. This will only show you errors and warnings.

To specifically narrow down to the 403 error, under “Code” type 403. Plesk will filter the log file to show only the 403 errors. You may find an entry starting with something like this:

ModSecurity: Access denied with code 403 (phase 2). Pattern match "(asfunction|data|javascript|livescript|mocha|vbscript):" at ARGS:input_5_7_data_canvas. [file "/etc/httpd/conf/modsecurity.d/rules/comodo/07_XSS_XSS.conf"] [line "227"] [id "212770"] [rev "4"] [msg "COMODO WAF: XSS Attack Detected|

Interpreting ModSecurity Logs

It’s important at this point to carefully review the cause of the error as shown in the logs and see if it looks like what you’re working on, or if it looks like something might actually be wrong. Firewalls are in place for your security, so we don’t want to shut things down unless we know we should!

In this case everything looks fine. Here’s the full log entry with the customer’s domain excluded:

ModSecurity: Access denied with code 403 (phase 2). Pattern match "(asfunction|data|javascript|livescript|mocha|vbscript):" at ARGS:input_5_7_data_canvas. [file "/etc/httpd/conf/modsecurity.d/rules/comodo/07_XSS_XSS.conf"] [line "227"] [id "212770"] [rev "4"] [msg "COMODO WAF: XSS Attack Detected||customerdomain.tld|F|2"] [data "Matched Data: data: found within ARGS:input_5_7_data_canvas: data:image/png;base64,ivborw0kggoaaaansuheugaaaswaaac0cayaaaaupxhvaaathkleqvr4xu2dvy4drrog20l8bcdbgrmsrg77cgw5kndteumrwhwfefms2xmz7sty7xuslhcpcuiawetobisiboynd0zxjcdnzun5667ueuza7ylnzhs/vfoc6prq7nnnz2dngqmfuaafcldghmaqweo0eqvqofeayoeikiacxsgasioxfq1farqawpgacqbamqoargjmtb2hjycn4bvvvgvffvtt+ouvv8lnn38e7t27fy5cufbjd+kgcpddkt4hxrx4ew7cubeepnz4rl8+/fttchp6wnwf6qakmajewax7wo8//hgodg7cr7/+gj766kpw1vdfhf39/saqunz5cnj69gl4/phx8zchctsgamaq1iqc1weffryuyv..."] [severity "CRITICAL"] [hostname "customerdomain.tld"] [uri "/specific_uri_requested/"] [unique_id "WKF7dUsZx0-CrULcny6MXQAAABA"]

It looks like what we’re doing here is submitting an image in encoded base64 format, and the firewall is getting pretty nervous about that! No matter. We know in this case that the issue comes up when submitting a form with Gravity Forms, and there is indeed an image involved, so we’re not concerned about it. Every case is different, though, so please ask if you need help interpreting! Simply open a ticket with the log entry included so we can analyze it quickly for you.

Solution 1 (temporary): Developing? Disable Firewall

If you’re currently making changes to the site, it’s best to simply disable the firewall entirely, since you’re likely to hit a number of roadblocks when submitting code blocks to the server via HTTP (ie: saving a CSS change) within WordPress.

Please remember to re-enable the firewall when you’re done editing the site, otherwise your site will not be protected from a large number of common attacks.

Here’s how to disable it:

  • In Plesk, go back to “Websites and Domains”
  • Click on “Web Application Firewall”.
  • Under “Web application firewall mode” Choose “Off”.
    Note: if you choose “Detection Only” our TCP level firewall will still pick up the log entries and institute temp bans.
  • Click OK or Apply to save.

Solution 2 (permanent): Excluding ModSec Rules

Let’s go ahead and exclude this rule from the firewall for the domain. In the error message we examined before there is a security rule ID. In this case it’s 212770, but yours will surely be different. Scan through the log entry until you find the ID, it’ll look like this: [id “212770”] then…

  • In Plesk, go back to “Websites and Domains”
  • Click on “Web Application Firewall”.
  • Under “Switch off security rules” enter the ID number you found in the log
  • Click OK or Apply to save.

Now try to do the action that caused the problem before.

If the issue is NOT resolved, and you’re still getting a 403 error, it’s likely that the action was triggering multiple firewall rules. Repeat the process until you’ve found all the rules causing problems. Note that the rule IDs are likely to be very similar, so look very closely when checking the latest log entries to ensure the ones you’re seeing are slightly different from the ones you’ve already excluded.


If you exclude a bunch of rules, then reach an error like this that doesn’t have an ID associated:

ModSecurity: Output filter: Response body too large (over limit of 524288, total not specified).

That means you’ll need to have those limits increased. If you have admin access to Plesk, you can insert the following under Tools & Settings > ModSecurity > Settings tab > Custom directives:

SecResponseBodyLimit 546870912
SecRequestBodyInMemoryLimit 546870912

If you do not have admin access to Plesk and you’re hosted with us, open up a ticket and we’ll take care of it for you!

Allen is a self professed geek and technology lover. He's always playing with one of his various websites, and loves helping customers with theirs. He can often be found with a coffee (light roast, please) in his hand and a smile on his face... or with a plate of bacon. Mmm, bacon.

Leave a Comment