I’ve had a look over here but didn’t find any details on the best file permissions. I also took a look at some of WordPress’s form’s questions over here too but anybody that suggests 777 obviously needs a little lesson in security.
In short my question is this. What permissions should I have for the following:
- root folder storing all the WordPress content
- wp-admin
- wp-content
- wp-includes
and then all the files in each of those folders?
When you setup WP you (the webserver) may need write access to the files. So the access rights may need to be loose.
After the setup you should tighten the access rights, according to Hardening WordPress all files except for wp-content should be writable by your user account only. wp-content must be writable by www-data too.
Maybe you want to change the contents in wp-content later on. In this case you could
su
,Whatever you do, make sure the files have rw permissions for www-data.
Giving the full access to all wp files to
www-data
user (which is in this case the web server user) can be dangerous.So rather do NOT do this:
It can be useful however in the moment when you’re installing or upgrading WordPress and its plug-ins. But when you finished it’s no longer a good idea to keep wp files owned by the web server.
It basically allows the web server to put or overwrite any file in your website.
This means that there is a possibility to take over your site if someone manage to use the web server (or a security hole in some .php script) to put some files in your website.
To protect your site against such an attack you should to the following:
Source and additional information: http://codex.wordpress.org/Hardening_WordPress
For those who have their wordpress root folder under their home folder:
** Ubuntu/apache
CREDIT Granting write permissions to www-data group
You want to call
usermod
on your user. So that would be:** Assuming
www-data
group existsCheck your user is in
www-data
group:groups yourUserName
You should get something like:
** youUserGroupName is usually similar to you user name
Recursively change group ownership of the wp-content folder keeping your user ownership
chown yourUserName:www-data -R youWebSiteFolder/wp-content/*
Change directory to youWebSiteFolder/wp-content/
cd youWebSiteFolder/wp-content
Recursively change group permissions of the folders and sub-folders to enable write permissions:
find . -type d -exec chmod -R 775 {} ;
** mode of `/home/yourUserName/youWebSiteFolder/wp-content/’ changed from 0755 (rwxr-xr-x) to 0775 (rwxrwxr-x)
Recursively change group permissions of the files and sub-files to enable write permissions:
find . -type f -exec chmod -R 664 {} ;
The result should look something like:
Equivalent to:
chmod -R ug+rw foldername
Permissions will be like 664 for files or 775 for directories.
P.s. if anyone encounters error
'could not create directory'
when updating a plugin, do:server@user:~/domainame.com$ sudo chown username:www-data -R wp-content
when you are at the root of your domain.
Assuming:
wp-config.php
hasFTP credentials on LocalHost
define('FS_METHOD','direct');
Best to read the wordpress documentation on this https://wordpress.org/support/article/changing-file-permissions/
I set permissions to:
In my case I created a specific user for WordPress which is different from the apache default user that prevent access from the web to those files owned by that user.
Then it gives permission to apache user to handle the upload folder and finally set secure enough file and folder permissions.
EDITED
If you’re using W3C Total Cache you should do the next also:
Then it’ll work!
EDITED
After a while developing WordPress sites I’d recommend different file permissions per environment:
In production, I wouldn’t give access to users to modify the filesystem, I’ll only allow them to upload resources and give access to some plugins specific folders to do backups, etc. But managing projects under Git and using deploy keys on the server, it isn’t good update plugins on staging nor production. I leave here the production file setup:
www-data:www-data = apache or nginx user and group
Staging will share the same production permissions as it should be a clone of it.
Finally, development environment will have access to update plugins, translations, everything…
www-data:www-data = apache or nginx user and group
your-user:root-group = your current user and the root group
These permissions will give you access to develop under
themes
andyour-plugin
folder without asking permission. The rest of the content will be owned by the Apache or Nginx user to allow WP to manage the filesystem.Before creating a git repo first run these commands:
Correct permissions for the file is 644
Correct permissions for the folder is 755
To change the permissions , use terminal and following commands.
755 for folders and 644 for files.
I think the below rules are recommended for a default wordpress site:
For folders inside wp-content, set 0755 permissions:
chmod -R 0755 plugins
chmod -R 0755 uploads
chmod -R 0755 upgrade
Let apache user be the owner for the above directories of wp-content:
chown apache uploads
chown apache upgrade
chown apache plugins
It actually depends on the plugins you plan to use as some plugins change the root document of the wordpress. but generally I recommend something like this for the wordpress directory.
This will assign the “root” (or whatever the user you are using) as the user in every single file/folder, R means recursive, so it just doesn’t stop at the “html” folder. if you didn’t use R, then it only applicable to the “html” directory.
This will set the owner/group of “wp-content” to “www-data” and thus allowing the web server to install the plugins through the admin panel.
This will set the permission of every single file in “html” folder (Including files in subdirectories) to 644, so outside people can’t execute any file, modify any file, group can’t execute any file, modify any file and only the user is allowed to modify/read files, but still even the user can’t execute any file. This is important because it prevents any kind of execution in “html” folder, also since the owner of the html folder and all other folders except the wp-content folder are “root” (or your user), the www-data can’t modify any file outside of the wp-content folder, so even if there is any vulnerability in the web server, and if someone accessed to the site unauthorizedly, they can’t delete the main site except the plugins.
This will restrict the permission of accessing to “wp-config.php” to user/group with rw-r—– these permissions.
And if a plugin or update complained it can’t update, then access to the SSH and use this command, and grant the temporary permission to “www-data” (web server) to update/install through the admin panel, and then revert back to the “root” or your user once it’s completed.
And in Nginx (same procedure for the apache)to protect the wp-admin folder from unauthorized accessing, and probing. apache2-utils is required for encrypting the password even if you have nginx installed, omit c if you plan to add more users to the same file.
Now visit this location
Use this codes to protect “wp-admin” folder with a password, now it will ask the password/username if you tried to access to the “wp-admin”. notice, here you use the “.htpasswd” file which contains the encrypted password.
Now restart the nginx.
Commands:
Where ftp-user is what user you are using to upload the files
To absolutely make sure that your website is secure and you are using correct permissions for your folders, use a security plugin like these:
https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/
https://en-ca.wordpress.org/plugins/wordfence/
These plugins will scan your WordPress installation and notify you about any potential issues. These will also warn you about any insecure folder permissions. In addition to that, these plugins will recommend you what permissions should be assigned to the folders.
I can’t tell you whether or not this is correct, but I am using a Bitnami image over Google Compute App Engine. I has having problems with plugins and migration, and after further messing things up by chmod’ing permissions, I found these three lines which solved all my problems. Not sure if it’s the proper way but worked for me.
For OS X use this command:
Define in wp_config file.
chown – changes ownership of files/dirs. Ie. owner of the file/dir changes to the specified one, but it doesn’t modify permissions.
Based on all the reading and agonizing on my own sites and after having been hacked I have come up with the above list that includes permissions for a security plugin for WordPress called Wordfence. (Not affiliated with it)
In our example, the wordpress document root is
/var/www/html/example.com/public_html
Open up the permissions so that www-data can write to the document root as follows:
Now from the dashboard in your site, as an admin you can perform updates.
Secure Site after Updates are finished by following these steps:
The above command changes permissions of everything in the wordpress install to the wordpress FTP user.
The above command ensures that the security plugin Wordfence has access to its logs. The uploads directory is also writeable by www-data.
The above command also ensures that the security plugin has required read write access for its proper function.
Directory and Files Permissions
Set the permissions for wp-config.php to 640 so that only wp-user can read this file and no one else. Permissions of 440 didn’t work for me with above file ownership.
WordPress automatic updates using SSH were working with fine with PHP5 but broke with PHP7.0 due to problems with php7.0-ssh2 bundeld with Ubuntu 16.04 and I couldn’t find how to install the right version and make it work. Fortunately a very reliable plugin called ssh-sftp-updater-support (free) makes automatic updates using SFTP possible without need for libssh2. So the above permissions never have to be loosened except in rare cases as needed.