WordPress File Permissions: 755, 644, wp-config.php and Ownership

This article is a localized edition of the Japanese original. Read the Japanese original

The baseline for WordPress file permissions is 755 for directories and 644 for files. wp-config.php, which holds your database credentials, should be readable by even fewer users. Beyond the numbers, check who owns the files and which user PHP runs as: getting both right prevents information leaks as well as "can't update" problems. The recommended values in this article were checked against the official "Hardening WordPress" guide as of November 2026.

How to read permission numbers

Permissions come in three sets, "owner, group, others", and each set is the sum of read (4), write (2) and execute (1).

"Execute (x)" on a directory is the permission to enter it. If you remove x from a directory, the files inside can no longer be read.

Recommended values for WordPress

There is no need for 777 (writable by everyone). On a shared server, other users on the same machine could overwrite your files.

Some hosting companies set their own recommended values, because each server runs PHP differently. If your host's manual lists values, follow those first.

Thinking about ownership

According to the official guide, files should be owned by your own user account and writable by you. Only the files WordPress needs to write to (uploads, and themes if you use the theme editor) should have their owner or group set so the web server (PHP) user can write to them.

Making everything belong to the web server user, as in chown -R www-data:www-data, lets PHP overwrite every file. If a plugin vulnerability is exploited, the damage spreads more easily, so check the current state before you decide.

When a plugin or core update asks for "Connection Information" (FTP hostname, username, password), the cause is usually this ownership mismatch. WordPress only chooses to write files directly when files created by PHP have the same owner as the WordPress files. Otherwise it asks to update via FTP. Fix it by aligning ownership, not by widening permissions to 777.

Check the current settings

Log in over SSH, move into the WordPress directory, and check values and ownership with these commands. Adjust the path to your environment.

cd /var/www/html

# Permission, owner and group of wp-config.php
stat -c '%a %U:%G %n' wp-config.php

# Find files and directories that others can write to
find . -perm -o=w ! -type l

# Find PHP files inside uploads (normally there are none)
find wp-content/uploads -type f -name '*.php'

Check which user PHP runs as for web requests in the server configuration (for example the user of the PHP-FPM pool) or in your host's manual. It is not necessarily the same user you log in with over SSH.

If you find unfamiliar PHP files in uploads, suspect tampering and record their timestamps and contents before deleting them.

Fix permissions in bulk

Run these in the WordPress directory. Take a backup first.

cd /var/www/html

# Set directories to 755 and files to 644
find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

# Restrict wp-config.php (example for a setup where PHP runs as the file owner)
chmod 600 wp-config.php

Choose the value for wp-config.php to match your environment:

• PHP runs as the same user that owns the files (most shared hosting, per-user PHP-FPM): 600 or 400
• You own the files and the web server reads them through the group: 640 or 440, with the group set to the web server's group

# Example: owner is you, group is the web server (www-data), mode 640
sudo chgrp www-data wp-config.php
chmod 640 wp-config.php

After the change, open the site and the admin area and confirm that pages load and you can log in. A blank white screen or an error means PHP cannot read wp-config.php. Set it back to 644, then review the owner and group.

With 400 or 440, plugins that write to wp-config.php (for example ones that write cache settings) will fail. Allow writing temporarily only while you configure such a plugin.

Keep wp-config.php from being read over the web

As long as PHP is working, opening wp-config.php in a browser does not show its contents. To keep the source from being served if PHP stops working, deny access on the web server side as well. On Apache 2.4, add this to the .htaccess in your WordPress directory (the old Order Deny,Allow / Deny from all syntax is for Apache 2.2):

<Files "wp-config.php">
    Require all denied
</Files>

The detailed steps are in "Denying access to wp-config.php".

.htaccess itself is already protected by Apache's default configuration (<Files ".ht*"> in httpd.conf).

The official guide also says you can move wp-config.php one directory above your WordPress install. If wp-config.php is not in the same directory, WordPress looks one level up. The official guide also notes the view that the benefit is small and that doing it carelessly can make things less safe. If you move it, make sure the parent directory is not publicly served.

Stop PHP from running in uploads

Because WordPress writes to uploads, it is a common place for attackers to drop files. If PHP cannot run there, a planted file does nothing.

On Apache 2.4, create wp-content/uploads/.htaccess with the following:

<FilesMatch "\.(php|phtml|phar)$">
    Require all denied
</FilesMatch>

To use Require in .htaccess, the server's AllowOverride must permit it. If it does not, you get a 500 error or the setting is ignored. After adding it, open a nonexistent PHP URL such as https://example.com/wp-content/uploads/test.php and confirm you get a 403 (if it is still a 404, the setting is not in effect).

On Nginx, put the following inside the server block, before the location ~ \.php$ block that handles PHP. Regex locations are checked from top to bottom and the first match wins.

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

After changing the configuration, check the syntax with nginx -t and then reload.

Note that WordPress media uploads reject file types that are not allowed (images, PDFs and so on) by default. You normally cannot upload a PHP file as media from the admin screen.

Cautions

• Back up your files and database before changing permissions.
• If you change permissions with an FTP client, some servers do not support bulk changes. When there are many files, SSH and find are faster and less likely to miss anything.
• If updates ask for FTP connection information, check ownership instead of widening permissions. See also "How to fix WordPress permission errors".
• Running the check commands above regularly (files writable by others, PHP inside uploads) helps you notice broken settings or tampering early.

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)