How to fix the 403 forbidden error in WordPress
Home » BLOG » WordPress » How to fix the 403 forbidden error in WordPress

How to fix the 403 forbidden error in WordPress

category:  WordPress

Recently I fixed the 403 error for one of my clients. There are many causes that your WordPress website can throw the 403 error. The solution depends on the cause. Today I will share how I fix the issue and what is the cause.

Find the root cause

If you are not a web developer, you should hire one to fix your issue. It is important to find the root cause so you will know what is the right solution for your issue. The web developer should explain to you what is the cause and how they solve your website.

Here is my client’s situation. He hosts the website on the web hosting that uses the Plesk panel. He installs the fresh WordPress and then installs the theme. For the theme, there is a pre-built template that you can import the demo content from the theme. He imports the demo content and the process gets stuck. No error shows on the screen. He searches for the solutions on the internet and tries those solutions but no luck. I don’t say the solutions on the internet are wrong but you have to find the root cause for your issue first then you will search for the right solution. Does that make sense?

For my client’s issue, I start by inspecting the error while importing the demo content. I see the 403 HTTP error coming from the ajax call. The request is to import the demo content which is the images and content. Now I know the request is blocked by my client’s server.

Next, I log in to my client’s server and check the error log for my client’s domain. As I expect, I see the “ModSecurity: Access denied with code 403” error message. This means the security rule from ModSecurity Web Application Firewall is very strict. The security rule may come from OWASP, Comodo, or a custom ruleset like Imunify360. In my case, the security ruleset comes from OWASP.

Solution

In order to let the request from the theme server go through, there are two temporary options.

Add the Rule ID ModSecurity temporary

  • Login to Plesk
  • Navigate to Website&Domain
  • Go to Web Application Firewall
  • Grab the rule id from the error log and put it into the “Switch off security rules” field. In my case, the rule is “[id “949110”]”. So I will put 949110 into the input field. If you have more rule ids in the error log, you will add those numbers and use a comma to separate them.
  • Save the change
  • Back to WordPress backend, perform the importing demo content again. It should work now.
  • After successfully importing the demo content, go back to “Switch off security rules” and remove the number we just add. Then save the change.
  • Contact your theme provider and give them the error log and explain the issue you have to them. So they can help to fix the issue from their end.
  • Contact your server support and give them the error log and explain the issue you have to them. So they can give you the suggestion or set some security rulesets for your domain.

Turn off ModSecurity temporary (don’t forget to turn it on after importing the content)

  • Login to Plesk
  • Navigate to Website&Domain
  • Go to Web Application Firewall
  • In Web application firewall mode, choose “Off
  • Save the change
  • Back to WordPress backend, perform the importing demo content again. It should work now.
  • After successfully importing the demo content, go back to Web application firewall mode and choose “On” or “Detection only” which is the same setting before you change to “Off“.
  • Save the change
  • Contact your theme provider and give them the error log and explain the issue you have to them. So they can help to fix the issue from their end.
  • Contact your server support and give them the error log and explain the issue you have to them. So they can give you the suggestion or set some security rulesets for your domain.

More information

  • You can find more ModSecurity settings for Plesk at WAF-ModSecurity doc.
  • From this WAF-ModSecurity doc, it says OWASP ModSecurity Core Rule Set (CRS). The CRS provides generic protection from unknown vulnerabilities often found in web applications. This rule set is shipped for free. It is known as a very restrictive rule set; it requires additional tuning for production use. When this rule set is selected, WordPress partly does not work, webmail and file sharing do not work either. You can use Atomic, Comodo, or Imunify360 rule sets instead.. I would recommend you to contact your server support and ask them for suggestions to choose which ModSecurity is good for WordPress on their server. Mostly the server support will help you to set and config the ModSecurity to meet your needs. I am not an expert on server configuration but I know what I want to achieve my goal for WordPress.

And that’s it for today.