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.
  • If you use the Divi theme/builder for WordPress, it will indicate something like “Error while saving the page” then provide a list of potential causes. This is *one* such possible cause, but not always the source, however finding the real error in the logs, as described below, is still the best next step.

This can happen seemingly out of the blue because our firewall rules are updated on a weekly basis; potentially adding new rules each week that could affect 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. (If you have Plesk reseller or admin access, it’ll be under Domains > the domain > Logs)
  • In the “Type” dropdown (the second from the left) un-check “access”. This will only show you errors and warnings.
  • The latest log entries will appear at the very bottom.

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

Because our web application firewall helps to block common attacks, you might see many ModSecurity entries in the log. The log entries that do not correspond with the action you’re taking that triggers the error must be ignored. Once you’ve found the correct log entry (probably the one closest to the bottom of the list), read on to learn how to interpret it.

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 the log entry below, everything looks fine. We’ve made certain parts bold to indicate what is relevant to us.

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”]

By ignoring what doesn’t make much sense or isn’t relevant, we can determine that the firewall rule found some kind of script which is submitting an image in encoded base64 format, and the firewall is getting pretty nervous about that! Understandable: it’s a random script with weird looking data…

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. In other words, we know we were the ones doing the submitting and not some random person on the Internet, so we’re not concerned about it.

Every case is different, though, so please ask if you need help interpreting! Simply open a ticket and include the log entry 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 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” or “Domains” and click on the domain.
  • 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 temporary bans. Off is best during development.
  • Click OK or Apply to save.

When you’re done developing, re-enable the firewall by following the same steps, but choosing “On” rather than “Off”.

Solution 2 (permanent): Excluding ModSec Rules

If users of your site will be taking the same action you did that triggered the 403 on a regular basis, then disabling the firewall entirely just won’t do!

Instead, 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 will trigger 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.

The most we’ve had to exclude in one sitting is about 5, so there’s a good chance you’ll get this fixed up within just 2 or 3 exclusions.


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!

Did you find this guide helpful? Check out our blog for more great content. Need help? Check out our fix my website service, or Platinum Management if you’re hosted with us, and we can take care of it for you!

About Allen Pooley

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