403 Forbidden errors when working on your website? Check the Firewalls.

A 403 forbidden error most frequently occurs when a web application firewall is protecting your site. Sometimes it will incorrectly think your legitimate actions are a malicious actor.

What is a web application firewall?

There are two commonly used web application firewalls (WAFs) these days:

1. A firewall that’s part of your website: for example, WordPress has many firewall plugins like WordFence, Securi, and iThemes Security.
2. A firewall that’s part of your web hosting server: One layer of our firewall solutions is a WAF. The software that enables this is called Mod Security or modsec.

The actual effectiveness of the WAF (regardless of whether it’s part of your website or part of the hosting) comes from the rules they utilize and regularly download/update. With our web hosting level WAF, these rules are provided by Imunify 360 – they are enabled on all shared servers as well as for anyone that has purchased an Imunify360 license for their VPS. If you don’t purchase Imunify360, you can still use Mod Security and select the Atomic or Comodo free rules instead. These free rules aren’t as smooth at avoiding false positives and aren’t updated as frequently as Imunify360.

Why is the WAF blocking me?! Handling False Positives.

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 so you can learn what is triggering it.

This can happen seemingly out of the blue because our firewall rules are updated on a daily basis; any of these updates could introduce a new rule or changed rule that might suddenly affect your site and/or actions. 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.

WordFence scans forbidden on basic hosting

For performance reasons WordFence scans are blocked on our shared servers. As an alternative to WordFence, Imunify360 Antivirus completes a weekly scan of all files. If any infected files are found on your site, you can view that report from within Plesk under Imunify. This cannot be overridden on shared servers.

For those with their own VPS, we have the same rules loaded, however you’re welcome to disable the rule responsible for this by logging in to to Plesk, going to Tools & Settings > Web Application Firewall > Settings. Look for the WordFence Scans blocked rule, and either remove it or comment it out by adding a # at the start of the line.

Try waiting or accessing from another IP

With some types of WAF blocks, you’re blocked because of too many attempts at doing something the firewall didn’t like, and it temporarily blocks your IP for about 30 minutes. You can simply try again later, or connect or disconnect from a VPN to change your IP and see if it works again. This might only be a temporary solution, as if you’re still triggering a firewall rule, it’ll likely occur again.

How to Find & Interpret Firewall Logs

If you do have a firewall as part of your website (like the WordPress ones described above), it would be a good idea to check their logs first, in case the block is occurring there.

If you don’t have a firewall as part of your website, or if you’ve already checked it and it’s not the cause of your forbidden errors, then the next step is to check the server logs to find out why it’s providing the forbidden error.

Our guide on how to use the Plesk file manager to analyze your website logs will help you find the logs and identify the correct log entries. Then come back here once you’ve found them for a more detailed analysis and solution.

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.

VERY IMPORTANT FOR SECURITY: 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). Be sure to enter only the number, no quotes, no brackets.
• Click OK or Apply to save.

Now try to complete the action that previously triggered the forbidden error.

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!