Set file permissions in WordPress correctly

File permissions determine who may read, write or execute a file or directory. On Linux they are shown as a three-digit octal number: the first digit applies to the owner, the second to the group, the third to everyone else. Each digit is made up of read (4), write (2) and execute (1). Incorrectly set permissions – above all the widespread but dangerous 777 – allow arbitrary users or hacked neighbour accounts on a shared server to change your files and inject malicious code. The WordPress recommendation is: 755 for directories, 644 for files and a stricter 600 or 640 for wp-config.php. This guide shows how to set these values via SSH or SFTP and which special cases to keep in mind.

What do 755 and 644 mean?

Step 1: Set directories to 755

Connect via SSH to the WordPress root directory and set all folders recursively:

cd /pfad/zu/wordpress
find . -type d -exec chmod 755 {} \;

Step 2: Set files to 644

find . -type f -exec chmod 644 {} \;

These two commands set the entire installation to safe defaults. Run them in this order (directories first, then files).

Step 3: Handle special cases

wp-config.php

The most sensitive file gets a stricter permission:

chmod 600 wp-config.php
# oder, falls der Webserver-Prozess über die Gruppe lesen muss:
chmod 640 wp-config.php

.htaccess

The .htaccess stays at 644. Do not make it writable by others, otherwise attackers could manipulate rewrite rules.

wp-content/uploads

The upload folder must be writable by the web server so that media uploads work. 755 for the folders is usually enough – what matters is that the owner is correct (see step 4). Do not assign 777 here. Important: no PHP files may be executable in uploads. Add the following to harden it:

# .htaccess in wp-content/uploads/ (Apache)
<Files *.php>
    Require all denied
</Files>

Step 4: Set the correct owner

Almost more important than the numbers is the owner of the files. All WordPress files should be owned by the user the web server or PHP process runs as (often www-data, apache, nginx or your SFTP user). Check and set:

# Aktuellen Eigentümer anzeigen
ls -l

# Eigentümer und Gruppe rekursiv setzen (Beispiel www-data)
sudo chown -R www-data:www-data /pfad/zu/wordpress

When the owner is correct, WordPress can run updates and uploads without you having to weaken the permissions. A common mistake is jumping to 777 when updates fail, even though in reality only the owner is wrong.

Everything at once (script)

#!/bin/bash
# Im WordPress-Stammverzeichnis ausführen
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 600 wp-config.php
echo "Dateiberechtigungen gesetzt: 755 Ordner, 644 Dateien, 600 wp-config.php"

How do I check the permissions?

1. Check a single file:

   ls -l wp-config.php index.php
   # Erwartet: -rw------- für wp-config.php, -rw-r--r-- für index.php

2. Search for insecure 777 permissions:

   find . -type d -perm 0777
   find . -type f -perm 0777
   # Erwartet: keine Ausgabe

3. Verify that PHP is not executed in the uploads folder by requesting a test file (should return 403).

Common mistakes

• 777 as a quick fix: It seems to fix update problems but opens the door wide. Almost always the owner is the real issue.
• Executable scripts in uploads: Without a PHP block in the upload folder an uploaded malicious file can be executed.
• Forgetting permissions after migration: After a server or host change the owner and permissions often no longer match – set them again.
• Shared hosting without SSH: There you set the permissions in the SFTP client (right click » permissions) or in the file manager of the hosting panel.

Frequently asked questions (FAQ)

Which file permissions are recommended for WordPress?

The WordPress recommendation is 755 for all directories, 644 for all regular files and a stricter 600 or 640 for wp-config.php. Directories need the execute bit so you can change into them, which is why they use 755 rather than 644.

Why is permission 777 dangerous in WordPress?

777 allows every user on the server to read, modify and execute the file or folder. On shared hosting a hacked neighbour account can inject malicious code into your installation this way. In almost all cases the real cause of update problems is not the permission but the wrong file owner.

Why is the file owner more important than the numbers?

All WordPress files should be owned by the user the web server or PHP process runs as (often www-data, apache or nginx). When the owner is correct, WordPress can run updates and uploads without you weakening the permissions to insecure values such as 777.

How do I stop PHP files from running in the upload folder?

Create a .htaccess in wp-content/uploads that denies access to PHP files (on Apache with a <Files> block and Require all denied). That way an uploaded malicious file cannot be executed as PHP even if it reaches the upload folder.

How does InspectWP help with file permissions?

InspectWP cannot read file system permissions from the outside, but it checks symptomatic consequences of insecure configurations: for example whether sensitive files are publicly accessible, whether PHP is executed in the upload directory or whether a directory listing is exposed. Such findings in the report are a strong signal to review the file and folder permissions.