File permissions in WordPress

Last Revised: October 2, 2021

When performing a new installation of WordPress, an element to keep in mind is who owns the system files and what permissions they have to be read or written. This is important because in times of a possible hack the problems can spread more or less.

The first thing is to make sure which user will be the one who accesses the files and to which group it belongs. As a general rule, the systems are configured for Apache HTTPD or nginx, so we can configure it for them. You can run this command by SSH from the WordPress installation folder.

In Apache HTTPD:

chown -R apache:apache ./

In nginx:

chown -R www-data:www-data ./

Subsequently, the [read/write/execute] permissions corresponding to the files must be given. In general we will give permissions 755 to the folders, and 644 to the files.

find /var/www/html/ -type d -exec chmod 755 {} ; find /var/www/html/ -type f -exec chmod 644 {} ;

If the system is properly configured, it could be a little more aggressive and block even more external access from unwanted users. In this case we will always leave the last of the three figures to zero. As far as possible this is the best and safest option.

find /var/www/html/ -type d -exec chmod 750 {} ; find /var/www/html/ -type f -exec chmod 640 {} ;

Once we have given these permissions to the entire WordPress, we will make a couple of exceptions with two very specific files: the [wp-config.php] and the [readme.html].

The first of them we have to let the system be able to read it, but that’s it, no one else should change or access.

chmod 600 wp-config.php

If we want to be somewhat more aggressive and that even the system itself is not able to modify it (the best thing is that no file modifies it), we can execute the command:

chmod 400 wp-config.php

In the first case the file could be read and written; in the second only read. This could mean that, if your WordPress needs to make any changes to the file, it cannot be applied and you have to modify it manually.

The second is a file that offers a small situation with security, the WordPress version. It is the simplest file to detect it and does not contribute anything else to the site, so we will block its reading, leaving only that it can be written when there are updates.

chmod 200 readme.html

Although if we want to put ourselves in more aggressive mode, this file should not be accessible at all, so we can remove all the permissions.

chmod 000 readme.html

Finally, in the same way that we have changed the permissions on the files, we are going to block their access publicly by web users. Thus, the system will be able to read or update them, but they will not be navigable.

In Apache HTTPD (inside the .htaccess file):

<files wp-config.php>
  deny from all
</files>
<files readme.html>
  deny from all
</files>
<files license.txt>
  deny from all
</files>

In nginx (within the site configuration file):

location ~ .php$ {
  location ~ wp-config {
    deny all;
  }
  location ~ /xmlrpc.php {
    limit_except POST {
      deny all;
    }
  }
}
location ~* readme.(html|txt) {
  deny all;
}
location ~* ^license.txt {
  deny all;
}

Finally, a detail that can come as a series active in Apache HTTPD servers is the list of the contents of the directories. To avoid this, and that the files of some folders such as [uploads] are not displayed, we must deactivate an option in the .htaccess.

In Apache HTTPD (inside the .htaccess file):

Options -Indexes

Seguir con Seguridad para WordPress


About this document

This document is regulated by the EUPL v1.2 license, published in WP SysAdmin and created by Javier Casares. Please, if you use this content in your website, your presentation or any material you distribute, remember to mention this site or its author, and having to put the material you create under EUPL license.