How to Audit Permissions for a WordPress Site in 2026
Auditing permissions for a WordPress site helps you identify who can do what across users, roles, plugins, themes, and server files.
It is one of the most effective ways to reduce account abuse, limit accidental changes, and tighten security before problems start.
Because WordPress combines application-level roles with hosting-level access, a useful audit has to look beyond the dashboard.
The fastest way to improve control is to review every permission layer in a structured order, then remove anything that does not match the site’s real operational needs.
What a WordPress permissions audit should cover
A complete audit should review access in four areas: WordPress user roles, individual account capabilities, media and content restrictions, and server-level permissions for files and folders.
If one layer is too broad, attackers or careless users can still create damage even when other protections are in place.
- User roles: Administrator, Editor, Author, Contributor, Subscriber, and any custom roles.
- User capabilities: Specific actions such as installing plugins, editing themes, or publishing posts.
- Media and content access: Upload, edit, delete, and publish controls.
- File and folder permissions: Ownership and access on wp-config.php, wp-content, plugins, themes, and uploads.
How to audit permissions for a WordPress site step by step
1. Inventory all users and roles
Start by exporting or listing every account with access to the site.
Focus on active users, inactive users, contractors, developers, agencies, support staff, and legacy accounts that may have been forgotten after a project ended.
Review each account and answer three questions: does this person still need access, is the assigned role appropriate, and is multi-factor authentication enabled for the account?
A common security issue is leaving old Administrator accounts active long after they are needed.
2. Review role assignments against actual responsibilities
WordPress roles are broad by default, so the assigned role should match the user’s current job.
For example, an Editor can publish and manage content across the site, while an Author can only manage their own posts.
If someone only needs to draft posts, giving them Administrator access is unnecessary and risky.
Check whether custom roles were created by a plugin or developer.
Some membership, LMS, and ecommerce plugins add their own capabilities, which can quietly expand access if they are not reviewed carefully.
3. Audit administrator access first
Administrator accounts deserve special attention because they can install plugins, edit code, change users, and alter site settings.
Keep the number of Administrator accounts as low as possible and verify that every account is tied to a real owner.
Remove shared admin logins where possible.
Shared credentials make it difficult to track changes and complicate incident response if something goes wrong.
4. Check plugin and theme permissions
Many security issues begin with plugins that add their own access rules.
Review whether plugins allow users to upload files, manage settings, access reports, or edit templates.
For example, a page builder, backup tool, or SEO plugin may expose privileged functions to roles that do not need them.
Also confirm whether the site allows theme editing inside the dashboard.
The built-in theme and plugin editors are convenient, but they can also be abused if an account is compromised.
In many environments, disabling file editing is a safer choice.
5. Inspect file and folder permissions on the server
File permissions determine who can read, write, or execute files on the hosting account.
On most WordPress installs, common baseline settings are 755 for directories and 644 for files, although hosting setups can vary.
The key is consistency and principle of least privilege.
Pay close attention to wp-config.php, .htaccess or web server configuration files, and any writable directories.
These should not be more permissive than necessary.
Excessive write access can allow malicious changes, PHP injection, or defacement.
- Directories: Usually 755.
- Files: Usually 644.
- wp-config.php: Often more restrictive than standard files.
- Uploads folder: Writable for media uploads, but not executable.
6. Verify ownership and group access
Permissions alone do not tell the full story.
File ownership and group membership can grant access through the operating system even when numeric permissions look normal.
Check whether the web server user, deployment user, and backup processes are set up safely and consistently.
In managed hosting or shared hosting environments, ask the provider how they handle ownership boundaries.
A good configuration reduces the chance that one site or process can affect another.
7. Audit user capabilities with a plugin or command-line tool
For deeper visibility, use a capabilities plugin or WP-CLI to inspect what each role can do.
This is especially useful when custom plugins add capabilities such as edit_product, manage_options, or upload_files.
Look for unnecessary permissions such as the ability to edit PHP files, install extensions, change site settings, or manage users.
Remove capabilities that are not needed for day-to-day work.
Common WordPress permission risks to look for
- Stale administrator accounts: Former staff or vendors still have full access.
- Overprivileged editors: Users can change content they should not control.
- Plugin-created capabilities: Custom permissions go unchecked after installation.
- Writable code paths: Theme or plugin files can be edited from the dashboard.
- Executable uploads: Upload directories allow scripts to run.
- Shared credentials: No accountability for changes.
How to document the audit so it stays useful
An audit is only valuable if the results are recorded in a way that supports future reviews.
Create a simple permissions log that includes the user name, role, reason for access, date reviewed, and any changes made.
Keep notes for plugin-specific capabilities and server-side exceptions as well.
This record makes it easier to spot permission drift later, especially after team changes, plugin updates, migrations, or redesign work.
It also helps when you need to explain why certain access levels were approved.
Best practices for reducing permission risk after the audit
Once the review is complete, convert the findings into standard access controls.
Limit Administrator accounts, assign the least powerful role that meets each user’s needs, and remove unused plugins or custom roles whenever possible.
- Enable multi-factor authentication for every privileged account.
- Use unique logins instead of shared usernames.
- Disable file editing in wp-config.php where appropriate.
- Review permissions after plugin updates and staff turnover.
- Restrict access to staging, production, and backup systems separately.
- Schedule recurring permission reviews, not just one-time checks.
For teams that manage multiple WordPress installations, standardizing role definitions across sites makes audits faster and more reliable.
It also reduces the chance that a contractor or editor has different privileges on different properties without a clear reason.
Tools that can help with a WordPress permissions audit
Several tools can speed up the audit process.
The right choice depends on whether you need dashboard visibility, server-level inspection, or both.
Common options include user role management plugins, security scanners, hosting control panels, and WP-CLI for command-line review.
- User Role Editor: Helps inspect and modify role capabilities.
- Members: Useful for role and capability management.
- Wordfence or Sucuri: Helpful for broader security review and file integrity checks.
- WP-CLI: Efficient for listing users, roles, and capabilities on larger sites.
- Hosting file manager or SSH: Necessary for checking file ownership and permissions.
When to audit permissions again
Revisit permissions after major events such as new hires, contractor departures, plugin installations, staging-to-production deployments, site migrations, and security incidents.
A good rule is to review critical access at least quarterly and immediately after any change that affects users or infrastructure.
If your site handles ecommerce, memberships, regulated data, or editorial workflows with many contributors, permissions should be treated as an ongoing control rather than a one-time maintenance task.