Lately, I have run in some security problems due to vulnerabilities in plugins. For this reason, I want to have a restrictive permission scheme unless i wish to install plugin or update wordpress.

When a WordPress is only running and serving content, that is it is not being updated, nor plugin or theme is being installed, which files & directories need to be writable? Is it only wp-content/uploads and wp-content/cache folder?

Lately, I have run in some security problems due to vulnerabilities in plugins. For this reason, I want to have a restrictive permission scheme unless i wish to install plugin or update wordpress.

When a WordPress is only running and serving content, that is it is not being updated, nor plugin or theme is being installed, which files & directories need to be writable? Is it only wp-content/uploads and wp-content/cache folder?

• permissions

• the wp-content/cache folder isn't a WordPress folder, it will be a custom folder from a plugin, you will need to ask the plugin vendor – Tom J Nowell ♦ Commented Jan 5, 2022 at 11:26
• 2 DISALLOW_FILE_MODS with only read-permission on wp-config.php might already help a lot in this regard – kero Commented Jan 5, 2022 at 11:33

1 Answer 1

There is no definitive answer to this, but I'd like to share my 2 cents anyways.

In practice, many plugins write to custom folders in ./wp-content/. Just checking one client site I see 6 custom folders in there (e.g. from security, backup, caching plugins, etc.).

Some themes and plugins may even expect that they are able to write inside their own folder (inside ./wp-content/themes/foo/ or ./wp-content/plugins/bar/), so restricting file access within ./wp-content/ will usually lead to problems.

Depending on the project, I usually do a mix of the following:

1. Have wp-config.php one level below the webroot. WordPress supports this out of the box and I consider it good practice to avoid accidental leakage of secure credentials.

/var/www/
        |- wp-config.php
/var/www/html/
             |- index.php
             |- wp-activate.php
             ...

2. Make wp-config.php read-only. This way you avoid hacks that read the file, remove restrictive elements, and overwrite it.

3. Set DISALLOW_FILE_EDIT (disallows editing via the editor in wp-admin) and DISALLOW_FILE_MODS (disallows any plugin/theme/core updates).

4. Regularly scan your complete installation and compare against original files. (Most security plugins have features of this, beware that this might be resource-intensive, so you might want to do it automated at night.)

5. Force secure passwords and if possible even 2FA for all backend users. (Forcing it for admins is a start, but there are "privilege escalation" scenarios, so forcing it for all users that have backend-access is usually best.)

6. Use advanced setups like Roots' Bedrock. If you manage your dependencies (core, plugin, theme) via composer, it is much easier to setup a new site. Bedrock also separates core from custom files better, so you can use more restrictive file-access.

7. Make related services internal. E.g. your DB and Redis do not need to be public, but only be accessible by WP itself.