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

A 403 forbidden error most frequently occurs when our security systems are protecting your site. Way more often than not, our web application firewall (called Mod Security or modsec) is protecting your website from automated hacking attempts.

However, in some cases, legitimate actions can be incorrectly identified as an attack and your action will be blocked. This is called a false positive. Here’s some common scenarios when this happens:

• Using any website builder, it might fail to save your changes
• 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.
• When adding javascript or PHP code through your website’s admin panel (and not the Plesk File Manager or FTP).

If you’re getting a 403 forbidden error that doesn’t match one of the actions above, you may wish to first check out our general guide to troubleshooting 403 errors.

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.

How to Find & Interpret Firewall Logs

The first step is to check the server logs to find out why it’s providing such an error. Check out our guide on how to use the Plesk file manager to analyze your website logs.

Because our web application firewall helps to block common attacks, you might see many ModSecurity entries in the log. It’s important to identify the log entries that directly correspond with the action you’re taking, otherwise, you’ll end up both weakening the firewall and not resolving the problem at the same time.

Firewall related errors will look similar to 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||customerdomain.tld|F|2"] 
[data "Matched Data: data: found within ARGS:input_5_7_data_canvas: data:image/png;base64,{{{{snipped}}}}] 
[severity "CRITICAL"] [hostname "customerdomain.tld"] 
[uri "/specific_uri_requested/"] 

Our example log entry above is a false-positive that occurred when submitting a Gravity Forms form with an image attachment.

We’ve snipped out a bunch of gobbledygook and replaced it with {{{{snipped}}}} to make this a bit more readable. We’ve also made certain parts bold to indicate what is most relevant to us.

Reading the bold sections in order, this error is stating that the firewall found:

• Access was denied with a forbidden error (code 403) (Note: if you do not see ‘code 403’ or ‘Access denied’, then the ModSecurity log entry you’re looking at is not relevant: move on to the next one. Some entries are for debugging or general information, not all are for blocking.)
• Some kind of script (javascript, livescript, etc)
• Using Rule ID 212770
• That it considered a XSS Attack (Cross Site Scripting)
• When it was submitting an image in encoded base64 format (data:image/png;base64)
• With severity “CRITICAL” (Note if you see a severity of DEBUG or WARNING, those are not likely to be responsible for a visible 403 error)
• On URI /specific_uri_requested/

The firewall is getting pretty nervous about that! Understandable: it’s a random script with weird looking data…

Since we know that the issue occurs when a legitimate user submits a Gravity Form, and there is indeed an image involved, this is likely a legitimate use-case and therefore the error is a false positive.

Please open a ticket if you need help interpreting! Make sure to include the log entry so we can analyze it quickly for you.

Below you’ll find two ways to work around these errors: 1) disabling the firewall (only recommended in select cases), and 2) excluding the particular rule(s) that are generating the false positive.

Solution 1 (temporary): Developing? Disable Firewall

If you’re currently developing 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 our example above, we identified the security rule ID 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 (usually one per line, if you have more than one).
• 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 has triggered multiple firewall rules. Repeat the process above until you’ve found and excluded all the rule IDs causing problems. Note that if there are multiple rule IDs causing this error, they 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 5, so there’s a good chance you’ll get this fixed up within just 2 or 3 exclusions.

Troubleshooting

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!