WordPress File Permissions and wp-config.php: A Practical Security Review

Security guidance · References checked 2 November 2026

In this guide

1. Start with ownership and the server’s execution model
2. Identify what really needs write access
3. Protect configuration without breaking WordPress
4. Understand what disabling the file editor does
5. Check for exposed backups and configuration copies
6. Apply narrow changes and test real functions
7. Document the expected state

When WordPress cannot upload an image or apply an update, changing everything to fully writable may appear to fix the problem. It can also give the wrong process or account permission to alter your website. File security is a question of ownership, necessary access and hosting architecture, not a single number copied into every directory.

This guide helps you organise a review with your host or developer. It deliberately avoids a universal recursive permission command. On a managed, shared, containerised or otherwise customised host, the appropriate settings can differ.

Start with ownership and the server’s execution model

Ask which account owns the website files and which operating-system user runs PHP. Find out how the host handles updates, deployments, uploads and backups. A setup where PHP runs as the site owner differs from one that relies on shared groups or a separate deployment account.

WordPress’s hardening documentation explains why writable areas and ownership must be considered together. It provides examples, but those examples still need to fit the actual hosting environment. WordPress hardening guidance.

Record the current state before changing it. Include the relevant paths, owner/group information, permissions and the problem you are trying to solve. This creates a way to compare the approved change with the result and to undo an unsuitable adjustment.

If you suspect an attacker has already modified files, preserve a copy before repairing permissions. Changing who can write a malicious file does not remove its contents or explain how it arrived.

Identify what really needs write access

Your uploads area needs an approved way to accept legitimate media. Cache, backup and temporary directories may also need application write access, depending on the installed software. Release code, configuration and deployment files need a different review.

Create a small access map. For each directory, identify the service that writes there, why it needs to write and who approved that requirement. If no one can explain an old backup or temporary directory, investigate it before removing it; it may belong to a process the business still uses.

Avoid treating the entire content directory as one category. It can contain plugins, themes, user uploads, must-use components and generated files. A permission change that works for one area can be wrong for another.

A practical review should also ask whether separate websites in the same hosting account can affect one another. The answer depends on account isolation and the server setup; changing one WordPress setting cannot establish that isolation.

Protect configuration without breaking WordPress

The configuration file can contain database connection details and authentication-related secrets. Keep it out of public file-sharing links, screenshots, tickets and source repositories. Do not store readable copies such as a text export in a publicly served directory.

The WordPress configuration handbook documents configuration options and their effects. Use the host-supported arrangement for your installation rather than moving the file or tightening its permissions blindly. A setting that prevents the PHP process from reading required configuration can take the website offline.

When a secret may have leaked, plan a coordinated rotation. Identify which services use it, preserve a working administrative route, replace it through an authorised method and verify the affected connections. A changed database password needs the matching application configuration; changing only one side can create an outage.

OWASP’s secrets-management guidance is useful for designing that lifecycle. This article does not recommend putting actual passwords into commands, article comments or analytics for convenience.

Understand what disabling the file editor does

Some installations choose to disable the dashboard’s built-in plugin/theme file editor. A developer may use the documented configuration constant:

define( 'DISALLOW_FILE_EDIT', true );

This is a configuration example for review, not an instruction to paste another definition into a production file. Check existing constants, syntax and the host’s policy first, and keep an appropriate private backup. Duplicate or misplaced definitions can cause warnings or other problems.

Disabling the dashboard editor does not make files immutable, remove existing malicious code or eliminate other ways to modify the server. It should not be described as a complete hardening strategy. It also differs from broader controls that affect installations and updates; understand the distinction before changing the update workflow.

Check for exposed backups and configuration copies

A private original configuration file is not enough if an old deployment archive contains the same secrets and is publicly downloadable. Review backup exports, database dumps, temporary folders, debug files and abandoned staging copies with the host.

Use authorised, limited checks of your own known paths. Do not download or circulate customer databases merely to demonstrate that a file is exposed. Confirm the access problem with the minimum information needed, then preserve the necessary evidence privately and remove public access through the appropriate server or storage control.

Decide where future backups will live and who can retrieve them. An archive placed inside the website’s public document root needs deliberate access protection; a difficult-to-guess filename alone is not that protection.

Apply narrow changes and test real functions

Make changes in staging where possible, with an owner and rollback instructions. Do not change every file owner or permission recursively to fix one upload failure. First identify whether the failure concerns ownership, disk space, a security restriction or an application error.

After the approved adjustment, test an allowed media upload, the relevant cache process, the site’s supported update procedure and scheduled tasks. Confirm that the sensitive configuration and backup material remain inaccessible to unauthorised visitors. Test as the appropriate roles, not only as an administrator.

Where code integrity matters, run a separate trusted-reference comparison. The file-integrity guide explains why correct permissions and unchanged release files are different claims.

Document the expected state

Leave a concise handover record: the paths reviewed, required writers, approved ownership/permission scheme, private backup location, changes made and functions tested. Record any managed-host exceptions rather than disguising them as mistakes.

Review this record after a migration, a deployment-process change or a new plugin that writes files. The goal is to give each legitimate process the access it needs, while making unnecessary write access and exposed copies easier to identify. No permission scheme guarantees protection from every application vulnerability or stolen account.

Published by NithuDev. About Nithu / Suthakaran Nithursan, website developer and security recovery specialist. Featured artwork is an AI-generated editorial illustration, not a photograph of a client, a real security incident or a verified tool result.