When I audit a WordPress site, I always look at the user list. On a surprising number of sites, almost everyone is an Administrator. The marketing intern, the freelance writer who left two years ago, the developer from the original build, the agency that handled ads once, and three different accounts for the owner.
Each of those accounts can install plugins, edit code, change settings and create new administrators. If any one of their passwords is weak, reused or stolen, the whole site is at risk. And in practice, stolen or misused admin accounts are behind many of the incidents I investigate.
The principle of least privilege says everyone should have exactly the access they need to do their job, and nothing more. WordPress has a solid system for this built in. It’s just underused.
Roles and capabilities explained
WordPress controls access with two concepts.
Capabilities are individual permissions, like edit_posts, publish_posts, upload_files, manage_options or install_plugins. There are dozens of them, and plugins can add their own.
Roles are named collections of capabilities. Each user is assigned a role, which determines what they can do.
The default roles, from most to least powerful, are:
- Super Admin: only on Multisite networks, controls the whole network.
- Administrator: full control over a single site, including plugins, themes, users and settings.
- Editor: can publish and manage all posts and pages, including other people’s, and moderate comments.
- Author: can write, publish and manage their own posts and upload files.
- Contributor: can write and edit their own posts but can’t publish them or upload files.
- Subscriber: can manage their own profile and little else.
WooCommerce adds Shop Manager, who can manage products, orders and store settings without full administrator rights, and Customer, similar to Subscriber.
Who should get which role
Here’s how I usually assign roles on business sites:
- Administrator: one or two people who are truly responsible for the site, such as the owner and the developer or maintenance provider. Nobody else.
- Editor: staff who manage content across the site, review others’ work and publish.
- Author: regular writers who publish their own posts without review.
- Contributor: guest writers and anyone whose work should be reviewed before publishing.
- Shop Manager: staff who process orders, manage products and handle customers in WooCommerce.
The key question for each person is: what do they actually do on the site each week? If the answer is “write blog posts”, they don’t need to install plugins.
Why Administrator access is dangerous
Administrators can do things that go far beyond content:
- Install and activate any plugin, including malicious ones.
- Edit theme and plugin code, if file editing isn’t disabled.
- Create new administrator accounts.
- Change the site URL and admin email address.
- Export all content and user data.
A compromised Editor account can deface content, which is bad. A compromised Administrator account can take over the entire site and the server it runs on, which is far worse.
Also note that Administrators and Editors can, by default, post unfiltered HTML, including JavaScript. On single sites, that’s part of their capability set. It’s another reason to be careful who gets these roles.
Separate accounts for separate people
Never share accounts. Each person should have their own login with their own password and two-factor authentication. Shared accounts make it impossible to know who did what, and you can’t remove one person’s access without changing the password for everyone.
For outside help, such as a developer fixing a problem or an agency setting up tracking, create a temporary account with the role they need, and remove it when the work is finished. Some plugins create time-limited accounts that expire automatically, which is handy for support access.
Creating custom roles
Sometimes the default roles don’t fit. Maybe you want an “SEO Manager” who can edit all posts and access SEO settings but not install plugins. Or a “Support” role that can view WooCommerce orders but not change store settings.
You can create custom roles with code. Do it once, ideally when a custom plugin is activated, because roles are stored in the database:
Note that add_role only works if the role doesn’t already exist. To change an existing role, use get_role and add or remove individual capabilities:
These changes persist in the database until you remove them, so don’t run them on every page load. Role editor plugins provide an interface for this, but be careful with them. It’s easy to accidentally give a low-level role a powerful capability.
Checking capabilities in code
If you build custom functionality, always check capabilities before letting someone perform an action. Check the specific capability, not the role name, because roles can be customised:
The edit_post check is a meta capability. WordPress maps it to the right primitive capabilities depending on the post’s status and author, so an Author can edit their own drafts but not other people’s posts.
Many plugin vulnerabilities come from missing or incorrect capability checks, where an AJAX handler or REST endpoint lets any logged-in user, or even anonymous visitors, perform admin-level actions.
Hardening for low-privilege users
Even Subscribers deserve attention, especially on sites with open registration, such as membership sites and stores.
- Check the default role. Under Settings, then General, make sure “New User Default Role” is Subscriber or Customer. Attackers who gain partial access sometimes change it to Administrator so anyone who registers gets full control.
- Disable registration if you don’t need it.
- Limit dashboard access. Many sites redirect customers and subscribers away from wp-admin to a front-end account page.
- Keep plugins updated. Many serious vulnerabilities only require a Subscriber account to exploit, which is trivial on sites with open registration.
Audit users regularly
User lists quietly grow over time. Every few months, review them:
For each account, ask:
- Does this person still need access?
- Is their role still appropriate?
- Do they use two-factor authentication?
- When did they last log in? An activity log or a login tracking plugin can tell you.
Remove accounts that are no longer needed. When deleting a user, WordPress asks whether to delete their content or assign it to someone else. Assign it, unless you really want the content gone.
Protect the most powerful accounts
For Administrator accounts specifically:
- Require two-factor authentication.
- Use unique usernames that aren’t easy to guess.
- Consider restricting admin login by IP address if your team works from fixed locations.
- Get alerts when an admin logs in from a new location or when a new administrator is created.
- Set DISALLOW_FILE_EDIT in wp-config.php so a stolen admin account can’t immediately edit PHP files.
Offboarding checklist
Most excess access builds up because nobody removes it when people leave. Make removing access part of offboarding, just like returning a laptop. When a staff member, freelancer or agency stops working on the site:
- Delete or downgrade their WordPress account, reassigning their content to someone else.
- Revoke any application passwords they created.
- Remove them from hosting, SFTP, DNS and Search Console.
- Change any shared passwords they knew, such as for third-party services.
- Check the activity log for anything they changed in their final days.
It takes ten minutes and closes one of the most common doors attackers use: old, forgotten accounts with weak or reused passwords.
Finally, write down who has which role and why. A one-page access list, reviewed every quarter, makes audits quick and makes it obvious when something has changed that shouldn’t have.
Frequently asked questions
How many administrators should a site have?
As few as possible. For most small businesses, one or two is enough: the owner and whoever maintains the site. Everyone else should have a lower role.
Can I give an Editor access to menus and widgets?
Yes. Adding the edit_theme_options capability to the Editor role allows access to menus, widgets and the Customizer, without granting plugin or user management.
What happens to a custom role if I deactivate the plugin that created it?
Roles are stored in the database, so they remain unless the plugin removes them on deactivation or uninstall. Users with that role keep it. If you remove a custom role, make sure those users are reassigned first.
Is it safe to use role editor plugins?
Generally yes, from reputable developers, but use them carefully. Granting a powerful capability like manage_options, edit_plugins or promote_users to a low-level role effectively gives that role administrator-level power.
Final thoughts
Least privilege isn’t about distrusting your team. It’s about limiting the damage any single compromised account can do. Give each person the lowest role that lets them do their job, use custom roles where the defaults don’t fit, check capabilities in custom code and review your users regularly. It’s one of the simplest security improvements you can make, and it costs nothing but a little thought.
