WordPress File Permissions Checklist: Keep Writable Paths Narrow in Production

Last reviewed: April 13, 2026

WordPress production environments often inherit file permissions from convenience rather than intent. A site launches, updates work, the web server can write where it needs to, and no one revisits the question until a plugin install fails, a backup restore changes ownership, or an operator notices that far more of the application tree is writable than anyone expected. That is a weak position because file permissions are not just a Unix housekeeping detail. They define how much of the site can be changed directly by the running application, by deployment tooling, and by anyone who manages to act through that execution path.

The practical goal is not to memorize one magic numeric mode and apply it everywhere. The goal is to keep production write access intentionally narrow. Teams should know which directories must be writable for normal operation, which ones should stay read-only, which user owns the files, how updates are performed, and how to tell when a host or control panel has expanded write access beyond what the stack really needs.

Who this guide is for

This article is for WordPress administrators, agencies, platform teams, and DevOps or security operators responsible for live production sites. It is especially relevant for shared hosting, aaPanel-style managed servers, stacks that perform in-place updates, and environments where deployments, web server users, and file owners are not always the same account.

Key takeaways

• There is no one-size-fits-all permission mode for every file, but the operational rule is consistent: keep only the minimum required paths writable in production.
• Ownership matters as much as numeric permissions. A “working” site can still be overexposed if the web server user owns or can modify too much of the codebase.
• A serious permissions review should distinguish normal runtime data paths from plugin, theme, and core code paths that should not be broadly writable during steady-state production.

WordPress file permissions and writable paths checklist

1. Map the file owner, group, and execution user before changing anything. The WordPress hardening documentation is explicit that correct file permissions depend on server setup and ownership model. That means the first useful question is not “should this be 755 or 775?” It is “which user owns these files, which user is running PHP or the web server, and which process actually needs write access?” Without that map, permission changes are guesswork and often make the site either too open or operationally brittle.
2. Distinguish runtime content paths from code paths. In many WordPress stacks, wp-content/uploads needs write access for normal media handling, while most plugin, theme, and core files do not need to be writable all the time. That boundary is the heart of the review. If broad write access exists across plugin and theme directories purely because it was convenient for manual updates or panel-based installs, the production surface is wider than it needs to be.
3. Check whether the web-serving process can modify code, not just upload content. WordPress’ own hardening guidance focuses on keeping permissions as strict as the hosting model allows. In production, the risky question is whether the process serving requests can also rewrite large parts of the application tree. If the web server or PHP user can modify plugins, themes, or core files directly, then a successful admin compromise, vulnerable plugin, or exploited file-write path has more room to turn into persistent code change. The smaller that writable area, the better.
4. Review wp-config.php separately and treat it as a special case. WordPress documentation explicitly calls out tighter handling for configuration files, and many teams already know it should not inherit the same casual permissions as the rest of the tree. This file often contains database credentials, salts, path configuration, and security-related constants. A permissions review should confirm that wp-config.php is not more exposed than necessary and that it is owned and protected intentionally.
5. Decide how updates are supposed to happen, then align write access with that method. If production updates are performed through CI, deployment tooling, or a control panel account, broad runtime write access for the web server may be unnecessary. If updates are intentionally handled in-place through WordPress, the team should still understand which directories that choice leaves writable and what tradeoff it creates. The point is to make the permissions model match the operational model instead of inheriting both accidentally.
6. Test actual writability on the paths that matter. A directory can look restricted in a quick listing and still be writable by the effective runtime user through ownership or group membership. Operators should check the real paths: uploads, cache or optimization directories, temporary working paths, and any location used by backup, image, or plugin tooling. Then test whether plugin or theme code directories are writable when they should not be. This is how you turn permissions from a visual assumption into an operational fact.
7. Record the approved writable-path baseline and re-check it after host changes. Control panels, restores, migrations, and manual file copies often drift ownership and permissions over time. A strong review ends with a documented baseline: which account owns the site, which paths are expected to be writable, which paths should stay read-only, and what commands verify that state. Without that baseline, the next restore or panel action quietly undoes the hardening work.

Useful commands or validation steps

# Review ownership and permissions for key WordPress paths
ls -ld .
ls -ld wp-admin wp-includes wp-content wp-content/uploads
find wp-content -maxdepth 2 -type d -printf '%M %u %g %p\n' | sort

# Review the configuration file separately
ls -l wp-config.php

# Check whether the web-serving user can write where it should not
sudo -u www-data test -w wp-content/plugins && echo writable || echo not-writable
sudo -u www-data test -w wp-content/uploads && echo writable || echo not-writable

The exact runtime user will vary by host and stack, so www-data is only an example. The point is to test effective writability using the same class of account that actually serves the application. Operators should adapt the user to their environment and verify both the directories that must be writable and the code paths that should stay protected.

What to verify before calling the permissions review complete

• The ownership model is understood. The team can explain who owns the files and which runtime account serves PHP or the web app.
• Normal runtime write paths are explicit. Uploads, caches, and other required data paths are known and justified.
• Code paths are not writable without a reason. Plugins, themes, and core files are not left broadly writable out of habit.
• wp-config.php is handled more tightly. Configuration is not inheriting casual permissions from the rest of the tree.
• The baseline is documented. The next operator can verify whether host changes or restores drifted the expected state.

Common mistakes

• Applying one numeric mode everywhere. That ignores ownership, runtime behavior, and the actual purpose of each path.
• Letting the web-serving user own the whole site tree by default. It may feel convenient, but it widens the impact of any file-write issue.
• Assuming a restore preserved the hardening model. Backup and migration workflows often change owners and modes silently.
• Forgetting that control panels and one-click tools influence permissions. What the stack looks like after a panel action may differ from what the team intended.
• Reviewing permissions without testing effective writability. Listings alone do not always tell you what the runtime account can actually change.

What to document or review next

• The approved owner, group, and runtime user model for the site or hosting cluster.
• The exact list of writable paths allowed in steady-state production.
• The expected permission and ownership checks to run after restores, migrations, or panel-driven maintenance.

Related reading

If the site still carries dormant code, pair this review with WordPress Inactive Plugin Removal Checklist: Reduce Dormant Code in Production. If privileged access is still too broad, follow up with WordPress Administrator Access Audit Checklist: Remove Stale Privileged Access.

References and further reading

• Advanced Administration Handbook: Hardening WordPress
• Advanced Administration Handbook: File Permissions
• Common APIs Handbook: wp-config.php
• WordPress Developer Blog: Website security checks with WP-CLI