WordPress File Permissions: The Complete Security Guide

WordPress file permissions are the foundation of your site’s security. Even the strongest login protection and the most secure plugins mean nothing if your file system is misconfigured. When permissions are too permissive, any uploaded malicious file or compromised plugin can execute code, modify core files, or steal data. I have seen sites with perfect login security get completely wiped because their wp-config.php was world-readable.

Here is the exact file permission setup every WordPress site should use, why each setting matters, and how to apply them correctly. These instructions apply to Linux servers running Apache or Nginx, which covers most WordPress hosting environments.

The WordPress File Permission Standard

The industry standard for WordPress file permissions is simple and has been the same for over a decade. Do not deviate from it unless you have a very specific reason and understand the security implications.

• All files: 644 (owner can read and write, everyone else can read)
• All directories: 755 (owner can read, write, and execute; everyone else can read and execute)
• wp-config.php: 600 or 640 (only the web server user can read it)
• .htaccess: 644 (web server needs to read it, but write access should be restricted to root only)

Apply these permissions with two commands:

find /path/to/wordpress -type f -exec chmod 644 {} \;
find /path/to/wordpress -type d -exec chmod 755 {} \;

Never use 777 permissions on any file or directory in your WordPress installation. If a plugin asks you to set 777 permissions, find a different plugin. There is almost never a legitimate reason for world-writable files on a production server. Plugins that require 777 are either poorly coded or outdated.

Secure wp-config.php

Your wp-config.php file contains your database credentials, authentication keys, and security salts. If an attacker reads this file, they have everything they need to take over your site. They can access your database, reset passwords, create admin accounts, and steal all your content. Set its permissions to 600 or 640 so only the web server user and root can read it:

chmod 600 /path/to/wordpress/wp-config.php

Some hosting environments require 640 instead of 600. If your site breaks after setting 600, try 640. The key principle is that the file should not be readable by anyone other than the web server user and your system administrator. Checking with ls -la wp-config.php shows you the current permissions.

Move wp-config.php One Level Up

WordPress allows you to place wp-config.php in the directory above your web root, one level above public_html or www. This means it is not accessible through any web request at all, even if your web server configuration has a flaw. This is an extra layer of protection that costs nothing to implement.

If your WordPress is installed at /var/www/your-site/public_html/, move wp-config.php to /var/www/your-site/. WordPress automatically looks for it there. Test by accessing your site after moving it. If everything works, the old file in the web root can be deleted.

Block PHP Execution in Uploads Directory

The wp-content/uploads/ directory stores media files like images, PDFs, and videos. If an attacker manages to upload a PHP file here through a vulnerable plugin or file upload feature, that file should not execute. Without this protection, a single uploaded PHP file can give an attacker full control of your site.

Create an .htaccess file inside wp-content/uploads/ with this content:

<Files "*.php">
  Require all denied
</Files>

This blocks direct execution of any PHP file in the uploads directory. Even if a malicious file gets uploaded, it cannot run, and the server returns a 403 Forbidden response instead. This is one of the most important hardening steps for any WordPress site.

Protect wp-includes from Direct Access

The wp-includes/ directory should not contain user-uploaded files, but an old plugin or theme vulnerability could place a backdoor there. Block PHP execution in wp-includes/ by adding this to your main .htaccess file:

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^wp-includes/(.*\.php)$ - [F,L]
</IfModule>

This blocks direct access to any PHP file inside wp-includes/. Only PHP files included internally by WordPress core will execute. If an attacker manages to drop a backdoor PHP file in this directory, direct browser access to it will be blocked.

Check Your Current Permissions

Before and after making changes, check what permissions your files and directories currently have. Run these commands to find security risks:

find /path/to/wordpress -type f -perm /o+w -ls | grep -v wp-content/uploads
find /path/to/wordpress -type d -perm /o+w -ls | grep -v wp-content/uploads

The first command finds files that are world-writable. The second finds world-writable directories. Anything returned by these commands is a security risk and should be locked down to 644 or 755 as appropriate. Run this check monthly or add it to a cron job for automatic monitoring.

What Happens If You Skip This

Incorrect file permissions are one of the most common causes of WordPress compromises. Here is what goes wrong when permissions are too loose:

• An attacker uploads a PHP shell through a vulnerable plugin, and it executes because the uploads directory allows PHP execution
• A compromised admin account modifies wp-config.php because it is writable by the web server
• A less-privileged user reads database credentials from wp-config.php because the file is world-readable
• Malware injects malicious code into theme files because the entire wp-content directory is writable

Real-world example: A site running a popular slider plugin had world-writable permissions on its uploads directory because the plugin installation instructions recommended it. An attacker uploaded a PHP webshell through a file upload field, executed commands, and defaced the entire site. The fix took two minutes (adding the .htaccess rule above), but the damage and cleanup took days.

The Bottom Line

Setting correct file permissions takes five minutes and is the single most effective file-level security measure you can take. Stick to 644 for files and 755 for directories. Lock down wp-config.php to 600. Block PHP execution in wp-content/uploads/. Automate the verification with a weekly cron job that checks for world-writable files. Pair file hardening with regular database optimization to keep your site running smoothly.

Ownership Matters: Who Owns the Files

Permissions are only half the story. File ownership matters just as much. The standard setup on most shared and VPS hosting uses a single user (www-data or nginx) for the web server and a different user (your SSH user) for file management. Setting the correct owner prevents the web server from modifying files it should not touch.

The recommended ownership model for WordPress:

• All files owned by your SSH user (e.g., root or deploy)
• Group set to the web server group (e.g., www-data)
• wp-content/ and wp-content/uploads/ writable by the web server

chown -R youruser:www-data /path/to/wordpress
chmod g+w /path/to/wordpress/wp-content
chmod g+w /path/to/wordpress/wp-content/uploads

With this setup, you manage files via SSH with your user, the web server serves files as www-data, and only wp-content and uploads are writable by the server. Everything else is read-only for the web server. If an attacker compromises a PHP file through a plugin vulnerability, they cannot modify wp-config.php, core WordPress files, or .htaccess files because the web server user does not have write access to them.

Set Up a File Integrity Check

WordPress core provides a checksum verification feature that checks all core files against the official WordPress repository. If any core file has been modified (by malware or by accident), it is flagged immediately. This is the fastest way to detect a compromise:

wp core verify-checksums

Run this after every permission change to ensure you have not accidentally broken a core file. Also run it periodically as part of your security monitoring routine. If checksums do not match, restore the affected files from a clean copy of WordPress before investigating further. Combined with proper file permissions, regular checksum verification gives you a reliable early warning system for file-level compromises.