WordPress file permissions decide which server users and processes can read, change, or execute a file. When permissions are too open, an attacker who reaches one vulnerable component may modify the rest of the site. When they are too restrictive, updates, uploads, caching, and page requests can fail.
The correct setup combines permissions with file ownership. Copying a number from a forum without understanding the hosting account may create a false sense of security, so this guide explains the model and a safer repair process.
How Linux file permissions work
Permissions are assigned to the file owner, the owner’s group, and everyone else. Each audience can receive read, write, or execute access. For directories, execute access means a process can enter the directory. Ordinary PHP files generally need to be read, not executed as operating-system programs.
A common shared-hosting baseline uses 755 for directories and 644 for files. This lets the owner write while the web process reads. It is not a universal rule: managed hosts, containers, and different PHP handlers can require different ownership and group settings.
Why chmod 777 is a dangerous shortcut
Setting a path to 777 gives every local user and process permission to write and execute. It may make an upload error disappear, but it removes an important security boundary. On shared or poorly isolated hosting, another compromised account may then alter your website.
If suspicious files keep returning, review Why WordPress Malware Keeps Coming Back before changing permissions. Reinfection often points to compromised credentials, hidden persistence, or another site on the account.
Secure WordPress permissions checklist
- Confirm which operating-system user owns the files and which user runs PHP.
- Follow the host’s documented ownership model rather than assuming every server is identical.
- Grant the least access needed: normally writable by the owner, readable by the web process, and not writable by everyone.
- Keep backup archives, database exports, and logs outside the public web root.
- Remove old installers, inactive extensions, and abandoned site copies.
- Test updates, media uploads, forms, caches, and scheduled jobs after changing access.
Protect wp-config.php and other sensitive files
The WordPress configuration file contains database connection details and security settings. It must remain readable by the process running WordPress, but it should not be exposed to unrelated accounts. Some servers support 640 or 600; others require 644. Use the host’s guidance and test the site after any change.
Backup files and debug logs can be even more valuable to an attacker. Permissions cannot protect an archive that the web server is configured to serve publicly, so move sensitive files outside the web root or explicitly deny web access.
Put these ideas to work.
From a specific fix to a complete website, we can help you define the scope and get it done.
Discuss my websiteCustom WordPress Web DevelopmentShare your goals. We typically reply within 4 hours with questions and practical next steps.
Fix ownership before permissions
When WordPress asks for FTP credentials or cannot update, mismatched ownership is often the actual cause. Making the content directory world-writable treats the symptom. Correct the owner and group, then grant write access only to directories that genuinely need it, such as uploads or a controlled cache.
For teams that need a repeatable process, Premier Sol’s WordPress maintenance and care plans combine updates, backups, monitoring, and routine security checks.
Repair permissions safely
Create a backup and record the existing ownership before making changes. Adjust directories and files separately rather than applying one value recursively to everything. Then verify the homepage, administration area, uploads, forms, checkout, cache clearing, plugin updates, and scheduled tasks.
Review the server error log when something fails. A 403 or 500 response can come from ownership, access-control rules, security modules, or PHP configuration—not only the numeric permission.
After correcting access, use the WordPress Security Audit Checklist to review administrator accounts, plugins, backups, headers, and monitoring. Permissions are one layer in a wider system.
Permissions after malware cleanup
Tightening access does not remove malware. Replace compromised code, remove persistence, rotate secrets, patch the vulnerable component, and then use ownership and permissions to limit what a compromised process could modify in the future.
If the site is actively compromised, the Emergency Hacked WordPress Site Recovery service covers cleanup, root-cause remediation, and hardening rather than applying permission changes in isolation.
For proactive protection, review Advanced WordPress Security Solutions and the real-world security implementation in Premier Sol’s case study.
See the complete cleanup and prevention workflow in the WordPress security recovery case study.
Frequently Asked Questions
What are the recommended WordPress file permissions?
A common secure baseline is 755 for directories and 644 for files, but the correct values depend on server ownership and hosting configuration. Sensitive configuration files may need tighter permissions.
Is chmod 777 ever safe for a WordPress website?
It should not be used as a permanent fix. World-writable permissions allow any process or account with server access to modify the path and can turn one compromise into a wider incident.
Why does WordPress ask for FTP credentials during an update?
WordPress may not have direct write access to the required files. Correct ownership and the server’s update method instead of making the entire installation writable.
Can incorrect permissions cause a 403 or 500 error?
Yes. Permissions that are too restrictive can block the web server, while incorrect ownership or server configuration can also trigger errors. Check logs before applying broad changes.
