WordPress File Permissions (Recommended Settings)

WordPress powers over 40% of the world's websites, making it the most frequent target of automated web vulnerability scanners, brute-force exploits, and malicious payload injections. The vast majority of compromised WordPress instances are breached not because of core software vulnerabilities, but because of improper file ownership and overly permissive permissions configured during server setup. Following the official WordPress security guidelines by applying chmod 755 to directories, chmod 644 to static files, and locking down wp-config.php to chmod 440 or chmod 400 establishes a robust barrier against server-level attacks.

Directories 755

In a standard WordPress installation, all directories—including wp-admin, wp-includes, and wp-content—must be configured with chmod 755 permissions:

# Apply 755 to all WordPress directories
find /var/www/html -type d -exec chmod 755 {} +

# Verify permissions on wp-content
ls -ld /var/www/html/wp-content
drwxr-xr-x 4 www-data www-data 4096 Jan 15 10:00 /var/www/html/wp-content

Mode chmod 755 provides read, write, and execute permissions to the directory owner, and read plus execute permissions to the group and the public (drwxr-xr-x). The execute bit is mandatory because Linux requires it for directory traversal; without it, web servers like Nginx or Apache cannot enter subdirectories or resolve URL paths. At the same time, restricting write access strictly to the owner prevents unauthorized users or rogue scripts from creating rogue folders or modifying directory structures.

Files 644

All regular WordPress files—including PHP source files, HTML assets, CSS stylesheets, JavaScript bundles, and media uploads—should be set to chmod 644:

# Apply 644 to all regular WordPress files
find /var/www/html -type f -exec chmod 644 {} +

# Check index.php and theme files
ls -l /var/www/html/index.php
-rw-r--r-- 1 www-data www-data 405 Jan 15 10:05 /var/www/html/index.php

Mode chmod 644 ensures the file owner can read and edit files, while external users and web server processes can read them (-rw-r--r--). Files never require the execute (x) bit in a PHP environment because the web server passes the PHP script to the PHP-FPM interpreter rather than executing it as a native standalone binary. Stripping the execute bit from all files ensures that even if an attacker manages to upload a suspicious file into an uploads folder, the operating system kernel will refuse to execute it directly.

wp-config.php 440/400

The single most critical file in any WordPress deployment is wp-config.php. It stores plaintext database credentials, secret cryptographic authentication salts, database table prefixes, and system paths. Leaving this file readable to other system accounts represents a catastrophic risk:

# Hardening wp-config.php with 440 (Owner & Group read-only)
chmod 440 /var/www/html/wp-config.php

# Or ultra-hardened 400 (Owner read-only)
chmod 400 /var/www/html/wp-config.php

# Verify the mode
ls -l /var/www/html/wp-config.php
-r--r----- 1 www-data www-data 3240 Jan 15 10:10 /var/www/html/wp-config.php

By enforcing chmod 440 (or chmod 400 if the web server is the direct owner), you completely block the "others" class from reading your database password. Furthermore, stripping write permissions from both the owner and the group ensures that unauthorized PHP scripts cannot overwrite your salts or redirect database queries during an ongoing exploit attempt.

Ownership and the Web Server User

A frequent dilemma for WordPress site administrators is understanding the relationship between file ownership and permissions. For WordPress to perform core updates, install plugins via the admin dashboard, or upload media files, the process running PHP (typically www-data on Ubuntu/Debian, or nginx/apache on RHEL/CentOS) must possess write access to the relevant directories.

# Set proper ownership for Ubuntu/Debian web servers
sudo chown -R www-data:www-data /var/www/html

# Alternative: Separate deployment user from web group
# User 'deployer' owns files, group 'www-data' writes to uploads
sudo chown -R deployer:www-data /var/www/html
find /var/www/html/wp-content/uploads -type d -exec chmod 775 {} +
find /var/www/html/wp-content/uploads -type f -exec chmod 664 {} +

In high-security production architectures, developers often assign file ownership to a non-web account (like deployer) and set directories to chmod 755 and files to chmod 644. Only the wp-content/uploads folder is opened to group write access via chmod 775, effectively preventing the web server process from modifying executable PHP code across the core installation.

Why Never 777

When inexperienced administrators encounter a "Missing a temporary folder" or "Upload directory is not writable" error in WordPress, many quickly run chmod -R 777 wp-content. This is the worst operational mistake in web hosting:

• chmod 777 grants universal read, write, and execute permissions (rwxrwxrwx) to every single process and user on the entire physical host.
• If another account or shared tenant on the server is compromised, an attacker can directly overwrite your WordPress theme files, inject hidden backlinks, or install a remote webshell.
• Security scanners and major managed hosting platforms automatically quarantine or take offline websites detected with 777 permissions.

Whenever you encounter an upload or write failure in WordPress, the problem is virtually always an ownership mismatch (the folder is owned by root instead of www-data), never a reason to use 777. Fix the ownership with chown, maintain 755 on directories and 644 on files, and your WordPress site will remain fast, functional, and secure.

Frequently Asked Questions