How to Fix the 403 Error in WordPress

How to fix 403 Forbidden error

403 errors are often caused by a misconfigured web server or firewall blocking access to a website. To fix a 403 Forbidden error, first check if the website is running in your browser. If it’s not, try changing your DNS server to Google Public DNS. Next, check if your computer’s firewall is blocking access to the site. If it is, add an exception for this website in your firewall settings.

How to fix 403 error on your WordPress blog

The 403 Forbidden error is a common error that WordPress users may encounter. This error is usually caused by incorrect permissions or a configuration issue.

1. Check access rights to folders and files

Every folder and file on your hosting has permissions – a parameter that determines who can do what with them. There are only three of them:

Read – you can view the contents of the file or folder;
Edit – you can make changes to a file, create or delete files in a folder;
Execute – you can run scripts or execute commands in certain folders.

Three categories of users can have rights:

Owner – usually the user who created the file, but in general, another user can be designated as the owner;
Group – users who are on the trusted list for the owner of a file or folder and may have special rights;
World – all other users, for example, site visitors.

Rights are denoted as a three-digit number, with each digit representing the rights of a certain category of users. Here are the standard permissions with which everything should work:

Folders – 755 or 750;
Files – 644 or 640.
The exception is the wp-config.php file on WordPress sites. Its permissions should be either 440 or 400.

2. Check the owner of the folders
Another popular cause of 403 error is incorrect owner of files or folders. The hosting permissions may be correct, but the file or folder may be owned by another user whose trusted user group does not include the web server. Because of this, the web server will be subject to the permissions of the other users, and they may not be sufficient.

VPS users may face this problem, on shared hosting it does not occur. The solution is to assign the owner of files and folders to the web server. To do this, you need to connect to the server via SSH in the command line and use the following command:

chown user:group /path/to/file

As user and group, you need to specify the username under which the web server runs processes. This can be apache or httpd. Depends on the distribution.

3. check the .htaccess file
.htaccess is a file with commands for the Apache web server that it must execute every time it processes a request to all or some specific pages of the site.

It can be used to set up redirects, change web server limits, and even deny access to certain pages of the site based on different parameters.

The 403 error can occur due to an error when composing a command, conflict of several commands or even several .htaccess files. Special deny commands with the words “Deny from …”, “Require IP …”, “R=403” or “RedirectMatch 403” can also cause this error.

If you’ve recently changed something in .htaccess, you can probably quickly find the command that’s causing the error. If not, the command may have appeared there after the plugin was installed. Or it was in there before, but this is the first time you’ve executed a request for which the command worked.

An easy way to find out if it’s .htaccess or not is to rename this file, which will cause the commands in it to stop working. If the 403 error disappears after that, the problem is in one of the directives. Then you will have to manually find out which one it is.

4. Check the index file in the root folder of the site
Every page has an index file. It is loaded every time someone visits the page in a browser. It is named in the configuration file of the web server.

If there is no index file with the name specified in the configuration file in the folder with the page someone is trying to access, the web server will try to display the contents of the folder where the page files are located. This is often disallowed in the default web server settings, so a 403 error is the norm in these situations.

Make sure you have the correct index file name in your web server configuration file. Let’s say you have only index.html there, but the file is actually called index.php. Then just add the correct extension to the directive.

On the Apache web server, the configuration files in which virtual hosts are typically defined are stored in these locations:

Main configuration file httpd.conf in /etc/httpd/conf/ or apache.conf in /etc/apache2/conf/ (depending on the distribution).
Additional configuration files in /etc/httpd/conf.d/, /etc/apache2/conf.d/, /etc/apache2/sites-available/, or /etc/apache2/sites-enabled/.
The Nginx web server has configuration files, where virtual hosts are usually prescribed, stored in these locations:

The main configuration file nginx.conf in the /etc/nginx/ directory.
Additional configuration files in /etc/nginx/conf.d/, /etc/nginx/sites-available/, or /etc/nginx/sites-enabled/.
Configuration files can be stored in other folders as well, if you manage the server using some kind of control panel. For example, for Webuzo it is /usr/local/apps/apache, and for Plesk it is /home/user/conf/.

5. Check your ModSecurity settings
ModSecurity is a firewall that protects your site from external threats. The way it works is that it blocks HTTP 403 Forbidden requests if it thinks they are malicious.

Sometimes the firewall works when it shouldn’t. For example, a visitor does something innocuous on the site, such as filling out a form and clicking “Submit”, but ModSecurity recognises it as SQL injection, blocks the action and displays a 403 error.

The solution is to disable the rule, but this can only be done on a VPS or dedicated server. On shared hosting, the firewall is configured by the provider and ordinary users do not have access to it. In this case, write to the provider’s support and ask to disable a specific rule for your site.

You can find out that the matter is in the firewall by logs. On a VPS or dedicated server they can be found by default in the following paths:

For Apache – /usr/local/apache/logs/modsec_audit.log;
For Nginx – /var/log/modsec_audit.log.
These logs will not be available on shared hosting. In this case, contact your hosting provider, explain the situation and ask them to check the logs.

6. Disable plugins
If the previous tips didn’t help and you have a CMS-based site, try checking plugins. They may be called modules, add-ons or extensions in different CMS. Any plugin is someone else’s code that you add to your site. There could be a bug in the code that causes an error. Or multiple plugins may conflict with each other.

An easy way to check if a plugin is causing a 403 error is to temporarily disable all plugins on the site. You can do this in the file manager in your hosting control panel.

7. Clear cookies
Error 403 indicates a problem with content permissions, and some cookies are just used to re-authorise a site. For example, thanks to cookies, browsers remember that we are already logged into an account on some sites.

Perhaps the 403 error occurs because something has changed on the server and it no longer accepts old cookies. Alternatively, try to access the site in a different browser. If it works, then it is definitely the browser.

8. Clear the cache
Perhaps some of the previous tips helped, but you don’t see any changes because the page with the error has been cached. As a rule, such pages are not cached, but different sites have different settings, so it’s better to clear the cache just in case.