Encountering a 403 while developing or troubleshooting a WordPress website means the server settings are blocking access to certain pages or resources. In this article, common causes of these errors are explored, such as incorrect file permissions, .htaccess misconfigurations, issues with security plugins, and more, including some edge cases or especially difficult scenarios. Each section offers practical solutions to help fix these issues quickly. Whether you’re a beginner or an experienced administrator, you’ll find valuable insights to manage and prevent access errors effectively.

Cause number 1: wrong file permissions

In WordPress, file permissions are an often hidden but of utmost importance for securinga web server. These permissions determine who can read, write, and execute files, affecting WordPress’s ability to perform operations like updating, caching, and plugin management. This does not mean it’s related to who can update plugins or themes when logged into WP-Admin –this can be set, but it’s not within the scope of file permissions–, but without the right permissions, WordPress won’t be able to function at all.

File permissions in Linux (which most WordPress servers use) have three key components:

  • Owner Permissions: Whether the owner of the file can read it, write in it, and execute it.
  • Group Permissions: What the user group associated with the file can do (read, write, execute).
  • Public Permissions: What all other users can do (read, write, execute).

What all these mean?

Read permissions are necessary for WordPress to access the files it needs to run properly. For example, reading configuration files to connect to the database. Write permissions are used by WordPress to modify files, which is necessary for operations like updating plugins, themes, or core updates. It also allows WordPress to modify .htaccess for URL rewriting rules. Execute permissions are typically needed on scripts that WordPress might run for maintenance tasks or scheduled jobs. Since this thing in particular is not WordPress-specific, more in general, this is what each permission means:

  • Read (r): This permission allows the contents of a file to be viewed and read. For directories, this permission grants the ability to list the contents of the directory.
  • Write (w): Write permission allows the content of the file to be modified or deleted. For a directory, having write permission means you can add or remove files from that directory.
  • Execute (x): For files, execute permission is required to run the file as a program or script on the server. For directories, execute permission allows the affected user or group to enter the directory, and access files and directories inside it.

Permissions can be represented numerically and often they are, for instance, 755 (rwxr-xr-x) where:

  • 7 stands for read (4), write (2), and execute (1) by the owner.
  • 5 stands for read and execute by the group and others.

To maintain security while ensuring functionality:

  • Directories should be set to 755 or 750, allowing the owner full access and limited or no access to others.
  • Files should generally be set to 644 or 640, allowing the owner to read and write while preventing others from making changes.
  • The wp-config.php file should be even more restricted, ideally set to 440 or 400 to prevent unauthorized access.

One thing is often seen is the use of 777 permissions, synonym with “everyone can do anything”, as a quick way to solve the problem, because it grants wide access. Setting permissions to 777 (read, write, execute for everyone) is extremely risky as it allows anyone on the server, including malicious scripts, to modify or execute files. Instead, assigning the right permissions to files and directories should suffice.

There are two main ways of setting the correct permissions, FTP clients and ssh access.

FTP Clients: Tools like FileZilla allow you to modify permissions. Simply right-click on a file, select ‘File Permissions’, and enter the numeric value needed (e.g., 644 for general files).

FileZilla is a free and open-source FTP (File Transfer Protocol) client used to transfer files between a local computer and a remote server. It supports FTP, SFTP, and FTPS and is available for Windows, macOS, and Linux. FileZilla is widely recognized for its powerful features.

Here is how FileZilla can be installed:

Windows:

  1. Visit the FileZilla website and download the FileZilla Client installation file.
  2. Open the installer and follow the on-screen instructions to install.
  3. Launch FileZilla once installed.

macOS:

  1. Download the FileZilla Client from the official website.
  2. Open the downloaded .dmg file and drag the FileZilla app to your Applications folder.
  3. Open FileZilla from the Applications folder.

Linux:

  1. Use your distribution’s package manager to install FileZilla. For Ubuntu, you can install it via the terminal with the command:
sudo apt-get install filezilla

Once installed, open FileZilla through your system’s application menu.

To connect to your server, which is of course a prerequisite to be able change the permissions, Launch FileZilla and go to File > Site Manager. Click on New Site and fill in your site’s details:

  • Host: The domain name or IP address of your server.
  • Port: Leave this blank to use the default FTP port 21, or enter 22 for SFTP.
  • Protocol: FTP – File Transfer Protocol, or SFTP – SSH File Transfer Protocol (more secure).
  • Logon Type: Select “Normal” and then enter your FTP username and password.

Click Connect to establish a connection to your server. All the above assumes that the web server has FTP/SFTP access. All these information, allong with the confirmation whether the server allows FTP/SFTP access, must be provided by the hosting provider.

In addition to SFTP, SSH can also be used. If you have shell access, use the chmod command to change permissions. For example, chmod 644 file.php sets the file to read and write by the owner, read by the group, and read by others.

SSH, or Secure Shell, is a network protocol that allows for secure remote login from one computer to another. It provides encrypted connections between clients and servers, which is crucial for managing sensitive data and configurations on web servers.

To use SSH, you’ll need SSH client software. Most Unix-based systems (including macOS and Linux) come with an SSH client pre-installed. Windows users can use PuTTY, a free SSH client, or the built-in SSH capabilities of Windows 10 and later.

Installing and Using SSH Clients:

  • Windows:
    • For Windows 10 and later, SSH is available natively. Open PowerShell or Command Prompt and type ssh.
    • Alternatively, download and install PuTTY from the PuTTY website. Once installed, launch PuTTY to configure your SSH connection.
  • macOS and Linux:
    • Open a terminal window.
    • SSH is typically ready to use and does not require installation.

To connect to the server:

Gather Your Credentials: You’ll need your server’s IP address or host, SSH port (usually 22, but not always), and your SSH username and password. This information is typically provided by your hosting provider. Once all these is at hand:

  1. Open a Terminal or Command Prompt/PuTTY.
  2. Connect to Your Server:

Once connected, you are ready to manage files and directories directly on your server.

You can leverage find to change all files and directories in your WordPress installation to what WordPress wants and expects. Navigate to your WordPress root directory and execute:

find . -type d -exec chmod 755 {} \; This command sets the permissions of all directories to 755.

find . -type f -exec chmod 644 {} \; This sets the permissions of all files to 644.

chmod 600 wp-config.php The wp-config.php file contains sensitive information and should be more restricted. This command sets the permissions so that only the owner has read and write access, enhancing the security of this critical file.

If none of these worked, for servers with SELinux enabled, file access issues might resemble standard permission errors. Using commands like getenforce or checking the audit logs with ausearch can help identify if SELinux policies are blocking WordPress operations. There’s more information on this and ways to get around this problem in the official WordPress documentation for file permissions.

Another potential cause related with file permissions is having the wrong owner. The chown (change owner) command is used to change the ownership of files and directories in Unix-like operating systems. In the context of a WordPress site, WordPress may need to write to files or directories, and incorrect ownership can prevent WordPress from updating itself, installing plugins, or uploading files.

When to Use chown:

  • Sometimes is needed after FTP operations, depending on how the server is configured. Files uploaded via FTP might be owned by the FTP account rather than the web server’s user, potentially leading to permission issues.
  • After Manual Installations or Configurations. If files were manually added by a system administrator, they might not be owned by the correct user for web server operations.

To change the ownership of all files and directories to the web server user (often www-data in Apache on Ubuntu), navigate to the root directory of your WordPress installation and run:

sudo chown -R www-data:www-data .

Replace www-data:www-data with the appropriate user and group for your server.

In a web server context, files and directories are owned by users and groups. It’s important that your WordPress files are owned by the correct user and group to maintain website functionality and security. The right user and group ensure that the web server has the necessary permissions to read, write, and execute files as needed by WordPress.

  • User: This is typically the account under which the web server (like Apache or Nginx) runs. For many Linux distributions, Apache runs under the www-data user, and Nginx often runs under nginx. However, this can vary based on how your server is set up.
  • Group: Similar to the user, the group associated with your web server process might also be www-data or nginx. Files need to be accessible by the group to allow server processes to execute them properly.

Via Terminal Command (for Apache/Nginx on Linux):

  • Open a terminal or connect to your server via SSH.
  • You can check which user is running the web server process with one of the following commands: ps aux | grep apache or ps aux | grep nginx.

If you’re using shared hosting or aren’t comfortable using terminal commands, your hosting provider can tell you under which user and group your web server is running. This is often the easiest way for those who manage their websites through a web hosting control panel.

Another method is to look at the configuration files for Apache or Nginx. For Apache, the configuration file is usually apache2.conf or httpd.conf, and for Nginx, it is nginx.conf. These files might specify a user and a group, although accessing these files might require root access:

cat /etc/apache2/apache2.conf | grep User
cat /etc/apache2/apache2.conf | grep Group

for nginx:

cat /etc/nginx/nginx.conf | grep user

Correcting .htaccess Misconfigurations to Solve WordPress 403 Errors

The .htaccess file is a powerful configuration file used by Apache-based web servers to manage settings at the directory level. Located in the root directory of your WordPress installation, it can control many important aspects of your site’s behavior, particularly URL redirection and permalinks.

Before diving into issues related to the .htaccess file, it’s crucial to determine whether your WordPress site is hosted on an Apache web server. The .htaccess file is specifically used by Apache servers to handle configurations like URL rewrites and access permissions. If your server is running on Nginx, IIS, or any other non-Apache server, the .htaccess file will not be present or relevant, and you can rule it out as a cause of the 403 Forbidden error.

Here are a few methods to check if your website is running on Apache:

  1. The simplest way is to ask your hosting provider directly. They can provide detailed information about the server environment your site is hosted on.
  2. Most hosting providers use control panels (like cPanel, Plesk, etc.) that often indicate the type of server. For example, in cPanel, the “Server Information” section usually lists the server software.
  3. You can sometimes identify the server type through the HTTP response headers, but please note this is not a bullet-proof way of identifting it.
    • Open your website in a web browser.
    • Right-click on the page, and select “Inspect” or “Inspect Element” to open the Developer Tools.
    • Go to the “Network” tab and refresh the page.
    • Click on the first entry, usually the request for the initial HTML document.
    • Look in the headers for a “Server” line, which may indicate whether Apache or another web server is being used.
  4. If you have the ability to run PHP scripts, which probably you have since you are using WordPress, you can create a simple phpinfo() file to find out detailed information about your server:
    • Create a new file called info.php.
    • Add the following PHP code: <?php phpinfo(); ?>
    • Upload this file to your web server and navigate to it (e.g., http://yourdomain.com/info.php).
    • Look for the “Server API” or “Loaded Modules” section to see if Apache-related items are listed.

In case you are indeed using Apache, when misconfigured, the .htaccess file can restrict access to your website, leading to 403 Forbidden errors.

Even a small typo can cause the entire web server to misinterpret the file, leading to broad access issues across the site. Also, rules intended to increase security or manage traffic can inadvertently block legitimate access. And finally, ppdates, plugin installations, or manual edits that tinker with .htaccess can corrupt this file.

Before making changes, save a copy of the existing .htaccess file. This allows you to restore the previous state if your changes do not resolve the problem or lead to other issues. Open your .htaccess file with a plain text editor and check for any obvious syntax mistakes. Ensure commands are properly formatted and closed. A quick way to determine if .htaccess is the cause of your 403 errors is to replace it with the default WordPress .htaccess code:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Save the file and check if your site becomes accessible. If resetting the .htaccess file fixes the issue, reintroduce customizations incrementally. After each change, verify that your site remains accessible. This process helps pinpoint the exact cause of the original error. If you’re unsure about making these changes, or if problems persist after your attempts to fix the .htaccess file, your web hosting provider can offer guidance and potentially identify configuration issues specific to their environment.

If none of these apply to you because you find out that your server does not use Apache:

  • Nginx uses nginx.conf and other configuration files instead of .htaccess. Issues similar to those caused by .htaccess in Apache (like rewrite rules or access restrictions) will need to be addressed in the Nginx configuration files.
  • IIS: Windows servers running Internet Information Services (IIS) use web.config instead of .htaccess for URL rewrites and other settings.
  • For these or other web servers, consult the specific server documentation or your hosting provider for guidance on how to address permission and access issues. Your hosting provider may be able to help as well.

Techniques for Handling Overzealous Security Plugins: Configuring and Deactivating WordPress Security Plugins

Security plugins are nice tools for protecting WordPress websites against unauthorized access and other security threats. However, these plugins can sometimes carry some problems, especially when misconfigured or conflicting. Sometimes they may block legitimate users from accessing your site, resulting in 403 Forbidden errors.

Security plugins work by analyzing incoming requests and blocking those that appear suspicious. This function relies heavily on a set of predefined or customizable rules that define what constitutes suspicious behavior. Here are common ways in which these plugins might inadvertently block legitimate access:

  • Security plugins might automatically block IP addresses that they deem to have exhibited malicious behavior. If a legitimate user’s IP address is mistakenly flagged (or if they are using an IP that was previously flagged), they could be denied access.
  • Some plugins implement firewall rules that are too strict, which can block users trying to perform routine actions that the plugin misinterprets as attacks, such as rapidly submitting forms.
  • Misconfiguration of security settings can lead to legitimate requests being categorized as threats. This often happens after updates to the plugin or WordPress core, where settings may revert to defaults or new features may introduce stricter rules.
  • Security plugins often include features to limit the rate of requests to the server, such as login attempts. If these limits are set too low, normal user behavior could trigger these limits and block access.

Try deactivating the plugin to see if the issue resolves. If it does, something within the plugin settings are likely responsible for the 403 errors. The problem here is that sometimes you can’t access the /wp-admin part of your WordPress because of the 403 itself. What you can do in these cases is deactivate the plugin by manipulating the plugin files directly. This can be done via FTP, cPanel’s File Manager, or using WP-CLI, a command-line tool for managing WordPress settings.

Via FTP or File Manager:

  • Access your site’s files by logging into your hosting account and navigating to the File Manager, or by connecting to your site via an FTP client like FileZilla.
  • Go to the wp-content/plugins directory.
  • Locate the folder for the security plugin you suspect is causing the issue.
  • Rename this folder; for example, change from sec-plugin to sec-plugin-disable. This will effectively deactivate the plugin as WordPress will not be able to locate its files.

Renaming the plugin directory is a quick way to deactivate it without affecting other site operations or plugin settings. This method is useful when you are locked out of your WordPress dashboard.

Via SSH and using the WP-CLI:

If you have SSH access to your server, using WP-CLI to manage plugins can be an efficient alternative. This is particularly useful for users who manage multiple WordPress sites or prefer working within a command-line interface.

  • First, connect to your server via SSH.
  • Navigate to the root directory of your WordPress installation.
  • Assuming you have the wp cli installed, to list all installed plugins, use the command: wp plugin list. Refer to its official documentation to learn more about how to install wp cli.
  • To deactivate a specific plugin, use: wp plugin deactivate plugin-name. Of course, replace plugin-name with the actual slug of the security plugin you wish to deactivate.

WP-CLI is a powerful tool that allows you to manage not just plugins but the entire WordPress installation via command line. It is especially handy if you need to script or automate tasks without using the WordPress admin interface.

Also, most security plugins provide logs that detail each action they take. Review these logs to see if they provide any clues about why legitimate requests are being blocked.

Preventative Measures for Directory Indexing Issues in WordPress to Keep 403 Errors Away

Directory indexing is a server feature of web servers that allows users to view a list of files in a web directory when no index file is present (such as index.php or index.html). When directory indexing is disabled, which is common on many web servers for security reasons, trying to access a directory without an index file will result in a 403 Forbidden error. This setting prevents unauthorized users from potentially viewing sensitive files in your directories.

Very popular web servers like Apache and Nginx often have directory indexing disabled by default. This is a way of preventing users from easily seeing all the files in a directory reduces the risk of exposing sensitive files or information. Also, forcing a proper index file to be present ensures that users are guided to the intended content, not just a list of files.

If you suspect that disabled directory indexing might be causing 403 Forbidden errors, here are some steps to diagnose and resolve the issue:

  1. Check Server Configuration:
    • For Apache, the directory options can be found in .htaccess files or the main Apache configuration files (apache2.conf or httpd.conf). Look for directives like Options -Indexes.
    • For Nginx, check the server block configurations in nginx.conf for directives like autoindex off;.
  2. Look for Index Files:
    • Verify that each directory intended for user access has an index.php or index.html file. This is especially important for directories accessed directly through a URL.

In typical WordPress installations, an index.php file is a core component that exists in the root directory and crucial subdirectories. This file serves as the entry point for WordPress’s PHP processing, handling all requests that do not correspond to actual files on the disk, such as specific post URLs. Because of this architecture, missing index.php files in essential directories are unusual and could indeed suggest deeper issues such as misconfiguration or (worst case) a compromised site.

One common setup error that might lead to 403 errors, even with existing index.php files, is an incorrectly specified document root in the web server’s configuration. If the document root is not correctly aligned with the location of the WordPress files, the server might fail to locate the index.php file, leading to a 403 error.

This can be solved by verifying the document root settings in your web server’s configuration files (apache2.conf, httpd.conf for Apache; nginx.conf for Nginx) to ensure it points to the directory where your WordPress files, including the main index.php, are located.

How to Fix 403 Errors for REST API in WordPress Network Multisite Environments

When managing a WordPress Multisite network, administrators may occasionally encounter 403 Forbidden errors specifically when attempting to access REST API endpoints. This issue can stem from several configuration nuances unique to Multisite setups, including .htaccess rules, network settings, or security plugins that may not be fully adapted to the multisite architecture.

In WordPress Multisite, REST API requests are processed slightly differently than in single-site installations. The network nature of the site can introduce complexities in routing requests, especially when URL structures are altered by custom setups or security configurations. A common scenario is where .htaccess rules or security configurations block access to the REST API path, misinterpreting these legitimate requests as potential security threats.

To effectively address a 403 error for REST API requests in a WordPress Multisite, follow these diagnostic steps:

Check the .htaccess file for overly restrictive rewrite rules or directives that might affect access to the wp-json path. Ensure that the rewrite rules explicitly allow access to this endpoint.

Example of a basic rule allowing REST API access:

RewriteRule ^wp-json/?(.*)$ - [L,NC]

Temporarily disable security plugins to see if the 403 error resolves. If it does, review the plugin settings for anything related to API access or rate limiting features that could be misconfigured. Adjust the settings of your security plugins to ensure they permit REST API requests. Look for settings related to JSON or API and configure them to allow requests from authenticated or recognized sources.

Ensure that the domain settings and path settings in your Multisite network administration are correctly configured within your wp-config.php file. Incorrect settings here can misroute API requests, leading to 403 errors.

Correctly Implementing check_admin_referer to Avoid 403 Errors

Encountering a 403 Forbidden error when dealing with the check_admin_referer function in WordPress can be particularly frustrating. This function is used to verify that the request to a page or action originates from a legitimate source, specifically to prevent Cross-Site Request Forgery (CSRF) attacks. However, improper handling or configuration can mistakenly block legitimate admin actions, resulting in a 403 error.

The check_admin_referer function ensures that a request comes from an expected page or action by checking the referrer against a known and expected nonce value (a “number used once” to ensure freshness of the request). If the check fails, WordPress may terminate the request with a 403 Forbidden error, interpreting it as a potential security threat.

If the nonce used in forms or links is not correctly implemented, check_admin_referer may fail. Sometimes, server or client-side caching might serve stale pages, including outdated nonces, which fail the check. Also, overly aggressive security configurations or plugins may strip out referrer data from requests, preventing check_admin_referer from validating the request properly. All these are usual causes for this error to show up.

To diagnose and address issues with check_admin_referer causing 403 errors, here is some steps that can be followed:

  1. Review the code where the nonce is created and where check_admin_referer is called. Ensure that the nonce is properly passed through the request and that its lifecycle allows for valid checking. Ensure that nonces are used consistently and correctly both when generated and validated. Review the WordPress Codex for best practices on nonce implementation.
  2. Disable any caching mechanisms temporarily to see if caching is causing the nonce to be outdated or mismatched. If a security plugin is found to be the cause, adjust its settings to allow referrer data to pass through or exclude admin pages from aggressive filtering rules.
  3. Disable security plugins to test if they are interfering with the transmission of referrer data or modifying request headers. Check server settings, particularly those that handle HTTP headers, to ensure they are not stripping out necessary information. Ensure that the server configuration supports full HTTP header transmission, especially the Referer header used by check_admin_referer.

Hotlink Protection: A Possible Cause of 403 Errors for Images

When your WordPress site displays 403 Forbidden errors specifically for images, one potential cause could be the misconfiguration of hotlink protection. Hotlink protection is a security measure used to prevent other websites from directly linking to files on your server, primarily used to save bandwidth and prevent unauthorized use of your media.

Hotlink protection works by examining the HTTP referer header of the request, which indicates the URL from where the request originated. If this referer is not recognized as part of your domain or is not on a predefined whitelist, the server denies access to the image, leading to a 403 Forbidden error. This is intended to block external sites from embedding your images but can sometimes also block legitimate access in some scenarios.

If your own site links images in a way that does not send the correct referer due to technical configurations or errors, your server might block these image requests. Also, modern browsers or privacy-focused extensions might strip HTTP referer data from web requests. If users with such configurations visit your site, they might encounter 403 errors when trying to load images.

Look into the .htaccess file or your server control panel settings where hotlink protection settings are managed. Review the rules to ensure they are correctly specifying which domains are allowed to access your images. Also, try accessing your site from different browsers, some with privacy extensions disabled, to see if the issue persists. This can help determine if browser settings are influencing the appearance of 403 errors.

Here’s another potential source for this error. Sometimes, WordPress site owners may choose to embed images directly from third-party domains that permit hotlinking. Although this practice can save on bandwidth costs and server storage, it can lead to unexpected 403 Forbidden errors due to various reasons related to the third-party server’s configuration and changes.

The third-party may update their hotlinking policies to restrict direct access to their files, leading to 403 errors on your site where these images are embedded, or implement or change referrer checks that do not recognize your site as a permitted referrer anymore. Also, they can delete the hosted images, or change the URL structure, rendering your links broken and possibly redirected to a 403 error page.

To determine if hotlinking changes at a third-party domain are causing image access issues, attempt to access the image URL directly in your browser. If you encounter a 403 error, this indicates the third-party server is now restricting access.

Final Thoughts on Troubleshooting WordPress 403 Issues

This has covered the most common reasons behind the frustrating 403 Forbidden errors on WordPress sites, along with some others a bit more perplexong. Hope this provide a clearer understanding of how file permissions, .htaccess configurations, security plugins, and server settings all play a role in website accessibility, as well as the tools and knowledge to identify and fix these issues, ensuring that your site is both secure and can be accessed.