WordPress User Roles and Permissions: Least Privilege in Practice

WordPress user roles are the cheapest security upgrade most websites will ever get, and almost nobody uses them properly. Roughly half the hacked sites I have cleaned up over the years had the same thing in common: five, eight, sometimes twelve administrator accounts, most of them belonging to people who wrote a blog post once in 2021, an agency that finished its contract years ago, or nobody anyone could name. Every one of those accounts was a full set of keys to the site, protected by whatever password its forgotten owner chose, and any one of them was enough for an attacker to install a plugin, edit a theme file and own the whole installation.

Roles fix this for free. WordPress ships with a capability system that lets you give every person exactly the access their job needs and nothing more – the principle security people call least privilege. This guide is the practical version I use on client sites: what each built-in role can actually do (including the surprising bits), who should be an administrator (almost nobody), how to set up content teams, what role to honestly give a client who owns the site, when custom roles are worth building, which capabilities are dangerous, and the audit routine that keeps user lists clean year after year.

Table of contents

• Why roles are free security
• The built-in roles decoded
• Least privilege for websites, in plain terms
• Who should be an administrator: the two-admin rule
• Editors vs authors: setting up a content team
• WooCommerce roles: what a shop manager can and cannot do
• What role to give a client, honestly
• Custom roles and capabilities: when and how
• Dangerous capabilities to lock down
• The user audit routine and offboarding checklist
• Agencies and multi-site portfolios: accounts and activity logs
• Frequently asked questions

Why roles are free security

Most security advice costs something – a plugin licence, a better host, developer hours. Roles cost nothing. They are built into WordPress core, they need no maintenance, and they directly shrink the two numbers attackers care about: how many accounts are worth attacking, and how much damage a stolen account can do.

Think about what a compromised account is worth. A stolen subscriber login gets an attacker a profile page. A stolen author login gets them the ability to publish spam posts – bad, visible, fixable. A stolen administrator login gets them everything: plugin installation (which means arbitrary PHP), theme file editing (same), user creation (persistence), database access through any number of admin tools, and the ability to quietly delete the evidence. The gap between “embarrassing afternoon” and “site rebuilt from backups, blacklisted by Google” is very often just the role attached to the phished account.

Passwords and two-factor authentication decide how hard an account is to steal – I have written a separate guide on WordPress login security, 2FA and passwords. Roles decide what the theft is worth. You need both, but roles are the half people skip, because handing out administrator to everyone is easy and nothing visibly breaks. Nothing visibly breaks right up until it does.

The built-in roles decoded

WordPress ships with five roles (six with WooCommerce, covered below). Everyone knows the names; fewer people know where the lines actually sit, and the surprises matter.

The surprising bits, learned the hard way across hundreds of client sites:

• Editors can delete every page on the site. People think of editors as “content only” and forget that content includes the homepage, the legal pages and the landing pages the ad budget points at. Editor is a powerful role; give it deliberately.
• Authors can delete their own published posts. If a departing team member is an author, their published work is one bulk action away from disappearing before you remove the account.
• Contributors cannot upload images. Almost every “guest posting” workflow discovers this in the first week and then wrongly promotes contributors to authors. There are better fixes – grant just the upload_files capability instead (see the custom roles section).
• Administrators and editors can post raw HTML and scripts. On single-site installs both roles carry the unfiltered_html capability, which means a compromised editor account can inject JavaScript into any page. More on that in the dangerous capabilities section.
• Subscriber is not useless. If your site has comments-with-login, gated downloads or a membership plugin, subscriber is the correct default for the public, and your registration setting should never default to anything higher. I still find sites where “New User Default Role” is set to author or even editor from some long-forgotten experiment.

Least privilege for websites, in plain terms

Least privilege is a grand phrase for a simple rule: every account gets the minimum access its actual, current job requires. Not the access the person might need someday, not the access that matches their seniority, and not the access that avoids an awkward conversation. The minimum, now, with an easy path to more when a real need appears.

For a WordPress site that translates into four working principles:

• Map people to tasks, not titles. The marketing director who approves posts twice a month needs editor, not administrator. Ownership of the company does not require ownership of the plugin screen. The question is never “how important is this person” – it is “which screens does this person use”.
• Default down, promote up. When in doubt, give the lower role. Promoting an author to editor takes ten seconds when a genuine need appears; discovering that an over-privileged account was phished takes a forensic weekend. The asymmetry is the whole argument.
• Access is per person and temporary by default. One account per human, named after the human, removed when the human leaves. A freelancer on a six-week project gets an account with an end date in your calendar, not a permanent login “in case we work together again”.
• Privilege applies to software too. Plugins run with full power, so every plugin you install is an administrator you cannot offboard. Least privilege thinking is one more reason to keep the plugin list short – a point I make at length in common WordPress security mistakes that get websites hacked.

None of this needs a budget. It needs one honest hour with the user list and a little willingness to demote people politely. In my experience the demoted people never notice, because the access they lose is access they never used.

Who should be an administrator: the two-admin rule

My rule on client sites is two administrators: one for the person ultimately responsible for the site (the owner, or the agency running it), and one for the developer or maintenance provider who does the technical work. That is it. Not the marketing team, not the intern who “sometimes needs to change things”, not the previous agency, and not a shared “admin” account whose password lives in a spreadsheet.

Why two rather than one: you need a second door. If the primary admin account is locked out – lost 2FA device, forgotten password with a broken mail server, or the account itself compromised and hijacked – the second administrator can recover the situation from inside WordPress instead of via database surgery. Two accounts, two different humans, two different password managers, both with two-factor authentication enforced.

Why not three or more: every additional administrator multiplies attack surface without adding recovery value. Each one is a phishing target whose success ends the game. Each one can create further administrators, so your user list’s tidiness depends on the discipline of its least disciplined admin. And each one widens the pool of people who can make site-breaking changes with no technical safety net. When I audit a site and find nine administrators, the story is always the same: nobody decided to have nine, the list just grew because administrator was the path of least resistance every time someone needed anything.

Practical notes that make the rule stick:

• Rename obvious usernames. An administrator called admin collects a noticeable share of the internet’s brute-force traffic. Use real names or non-obvious handles; the username is half of a credential pair.
• Give admins a second, lower account if they also write. A site owner who blogs weekly should write as an editor and keep the administrator login for administration. It sounds fussy; it means their daily-use, always-logged-in browser session is not a master key.
• Enforce 2FA on administrators before anyone else. If you roll out two-factor gradually, admins go first, no exceptions.

Editors vs authors: setting up a content team

Content teams are where role design either works quietly or fails loudly. The pattern that works, from single-blogger sites up to teams publishing daily:

• One or two editors. The people who approve, schedule and fix content. They can edit everything, so this is a trust position – and because editors can publish raw HTML, their accounts deserve admin-grade password and 2FA discipline.
• Authors for regular writers. Staff who research, write and publish under their own names. They cannot damage each other’s work or the site’s pages, which makes author the right ceiling for most of the team.
• Contributors for occasional and guest writers. Everything they write waits for an editor’s approval, which is exactly what you want from someone you barely know. The missing image-upload capability is genuinely annoying; fix it by granting upload_files to the contributor role with a capability plugin or three lines of code, rather than promoting guests to author.
• Subscriber for everyone else. Commenters, newsletter sign-ups that create accounts, membership users. Check the “New User Default Role” setting under Settings, General – it must say subscriber.

Two workflow notes. First, WordPress shows pending contributor posts to editors with no notification by default; if you run a review workflow, add a notification plugin or a simple weekly check, or drafts will quietly pile up. Second, resist the temptation to make the whole team editors “so nobody is blocked”. The block is the feature: a review step is the difference between a typo reaching one editor and reaching your entire mailing list.

WooCommerce roles: what a shop manager can and cannot do

WooCommerce adds two roles. Customer is subscriber with purchase history attached – it exists so checkout can create accounts, and you never assign it manually. Shop manager is the interesting one, and it is the role most store owners’ staff should have instead of administrator.

A shop manager can run the commercial side of the store: view, create and edit orders, process refunds through the payment gateway’s supported flow, manage products, stock and prices, create and edit coupons, view all WooCommerce reports and manage customer records. They also carry editor-level content capabilities, so they can maintain shop-adjacent pages like delivery information and FAQs.

What a shop manager cannot do is the part that protects you: install or activate plugins, change WooCommerce settings (payment gateways, tax rates, shipping zones, emails), switch themes or touch site-level settings. In other words, the person handling daily orders cannot accidentally disconnect Stripe, break the tax setup or install a “free shipping bar” plugin from a dubious source during a busy afternoon.

The mapping I use on store builds: owner and developer are the two administrators; everyone who processes orders, manages stock or answers customer emails is a shop manager; content and marketing people are editors or authors on the blog side. One caution: some WooCommerce extensions add their own settings screens visible to shop managers, and a few register their own capabilities carelessly. After installing a significant extension, log in as a shop manager once and check what they can now see. Five minutes, occasionally very informative.

What role to give a client, honestly

The awkward question on every handover: the client owns the site, so surely they get administrator? My honest answer is yes – ownership means access, and a handover that withholds the administrator credentials is not a handover, it is a hostage situation. I build sites so that the client could fire me tomorrow and lose nothing, and I put that in writing (my website handover checklist spells out exactly what a client should demand, from any developer).

But there is a difference between having the keys and using them daily. What I actually set up is administrator with guardrails, plus a working environment that makes the administrator login unnecessary:

• The client gets an administrator account, stored in their password manager, with 2FA, used for genuinely administrative moments: reviewing users, authorising a new plugin, changing payment details.
• They also get an editor account for daily work. Posts, pages, products, media – everything they touch weekly lives inside the editor role, so the account that is logged in on three devices is not the master key.
• Site-wide content lives in options pages, not in the settings screens. This is my ACF options approach: phone numbers, opening hours, footer text, announcement banners, social links – all editable through a friendly “Site Settings” options page built with Advanced Custom Fields, readable by the editor role. The client edits everything they legitimately need without ever seeing the real WordPress settings, where a mistyped site URL can take the whole site down.
• File editing is disabled in code (next section), so even the administrator account cannot be talked into pasting a “small snippet” into the theme editor by a tutorial or a scammer.

Framed this way, clients do not experience least privilege as distrust. They experience a tidy site where the everyday screens contain everything they need and none of the things that break. In twelve years I have never had a client complain about this arrangement – I have had several thank me after their editor-level account was phished and the attacker found nothing worth stealing.

Custom roles and capabilities: when and how

The five built-in roles cover most sites. Reach for custom roles when a real job in the organisation does not match any built-in shape – not because a plugin’s marketing page suggested it. Genuine examples from my own projects: an “HR editor” who may edit job listings (a custom post type) but no other content; a “translator” role limited to editing translations; a “franchise manager” who edits one location’s pages; an “accounts” role that can view WooCommerce orders and reports but not edit products.

Two ways to build them. For one-off tweaks, a capability plugin like Members or User Role Editor is fine: create a role, tick capabilities, done. For anything that is part of how the site works, I put roles in code – in the theme or a small custom plugin – so they survive plugin changes, deploy with the site and are documented in version control. The core API is small:

add_role( 'job_editor', 'Job Editor', array(
    'read'         => true,
    'upload_files' => true,
) );

$role = get_role( 'job_editor' );
$role->add_cap( 'edit_jobs' );
$role->add_cap( 'edit_published_jobs' );
$role->add_cap( 'publish_jobs' );

The custom post type registers with 'capability_type' => 'job' and 'map_meta_cap' => true, so job capabilities are separate from post capabilities and the new role touches nothing else. Run add_role() once on activation, not on every page load – roles are stored in the database, and re-adding them on every request is a common performance mistake.

Three rules that keep custom roles from becoming their own mess. Keep the count low: if you have eight custom roles, you have designed an access matrix nobody will maintain. Name them after jobs, not people: the role outlives the employee. And prefer adding a capability to an existing role over inventing a new role – the contributor-plus-uploads fix is one capability, not a “Guest Author Pro” role. This is exactly the kind of small, boring, well-tested code I build inside larger projects – it usually lands in the site’s utility plugin alongside the post types, as part of custom WordPress plugin development.

Dangerous capabilities to lock down

A few capabilities deserve special attention because they quietly turn “content access” into “code execution”.

• File editing: disable it everywhere. The built-in theme and plugin file editors let any administrator edit live PHP from the browser. Attackers who steal an admin session use it within minutes to plant a backdoor; legitimate users use it to paste snippets from tutorials into a live theme with no backup and no syntax check. No client site of mine ships without define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php. On maintenance contracts where I control deployments, I also set DISALLOW_FILE_MODS, which additionally blocks plugin and theme installation from the dashboard – updates then happen through the deployment process, not through whoever is logged in.
• unfiltered_html: know who has it. This capability lets a user publish raw HTML including <script> tags. On single-site installs, administrators and editors have it by default; on multisite, only super admins do. It means every editor account is a potential stored-XSS vector: phish an editor, inject a script into a popular page, harvest every visitor. If your editors never legitimately paste script embeds, remove the capability from the editor role with a capability plugin, or define DISALLOW_UNFILTERED_HTML in config and grant embeds another way.
• create_users and promote_users. Anyone with these can mint new administrators, so they are the persistence mechanism in most compromises I clean up: the attacker’s first move is a spare admin account with an innocent name. These belong to administrators only – some role plugins let you hand them out casually, and you should not.
• edit_users on membership sites. A user editor can change other users’ email addresses, which enables password-reset takeover of those accounts. Treat it as adjacent to administrator.
• import and export. The importer can execute more than people expect, and the exporter hands over your entire content database in one file. Neither belongs below administrator.

The theme here: WordPress’s defaults date from a friendlier internet. Trimming these capabilities costs your team almost nothing day to day and removes the highest-value moves from an attacker’s playbook.

The user audit routine and offboarding checklist

Roles decay. People leave, projects end, plugins create service accounts, and eighteen months later the user list is fiction. The fix is a boring quarterly routine – fifteen minutes on a recurring calendar entry:

1. List all users sorted by role, administrators first. In Users, click the role filter links at the top – the counts alone are often the whole diagnosis.
2. Question every administrator by name. For each one: which human is this, do they still work here, have they used admin powers in the last quarter? Anything without three good answers gets demoted or deleted today, not “when we get round to it”.
3. Match every remaining account to a real, current person. Ex-employees, finished freelancers, the SEO agency from two contracts ago, test accounts called test2 – remove them. WordPress asks what to do with their content when you delete a user; always attribute it to another user rather than deleting it.
4. Check last login dates. Core does not record logins; any decent activity log or security plugin does. An account that has not logged in for a year is either abandoned (delete it) or a service account (document it).
5. Verify the settings that create users: “Anyone can register” off unless the site genuinely needs it, default role subscriber, and 2FA enforced for administrators and editors.

Offboarding is the same list compressed into the day someone leaves: delete or demote their account immediately, attribute content to a colleague, rotate any shared secrets they had (hosting panel, FTP, database, API keys – and if they knew a shared login, that password changes today), remove them from the password manager vault, and check the activity log for surprises in their final weeks. Not because you distrust the person – because from now on, their credentials are only a liability. Companies do this within the hour for payroll systems and within a decade for their website; the website is the one on the public internet.

Agencies and multi-site portfolios: accounts and activity logs

Agencies managing twenty or fifty client sites multiply every mistake in this guide by the portfolio size, and one mistake dominates: the shared login. One “agency” administrator account per site, same email, same password in a shared spreadsheet, used by whoever happens to be doing the work. It fails every test at once – no accountability (the activity log says “agency” did everything), no offboarding (when a team member leaves, the password must change on fifty sites, so it changes on none), and one leaked password compromises the entire client base.

The professional setup costs a little discipline and no money:

• Per-person accounts on every site. Each team member who needs access to a client site gets their own named account there, at the lowest role that does their job – developers as administrators, content people as editors. When someone leaves the agency, you delete one identifiable account per site, and the rest of the team is untouched.
• A management layer instead of memory. Tools like MainWP or ManageWP give you one dashboard for updates, backups and user management across the portfolio, so “remove Priya from all 40 sites” is a task, not an archaeology project. Keep the management tool itself behind 2FA – it is the most privileged account you own.
• Activity logging on every managed site. A plugin like WP Activity Log or Simple History records who logged in, what they changed, which plugins were installed and when roles changed. On a quiet site it costs nothing; on the day something breaks or a client asks “who changed our homepage”, it is the difference between an answer and a shrug. Logs also make the quarterly audit fast, because last-login and role-change history are right there.
• Write the access story into the contract. Clients should know which agency people have access, at what level, and that access ends with the contract. It is a selling point: an agency that can answer “who can touch our site” precisely is an agency that takes the client’s risk seriously.

This is also, frankly, a service worth paying for. On my maintenance and security plans, the quarterly user audit, activity log review and role hygiene are standing items – not because they are glamorous work, but because they are the items that keep the emergency calls from happening.

Want your user list audited properly?

I offer WordPress maintenance and security care that includes exactly this: a full user and role audit, least privilege cleanup, file editor lockdown, 2FA rollout and activity logging – plus updates, backups and monitoring, for sites and stores in Europe, the UK, the US and Australia. See the WordPress maintenance and security service and my portfolio, or tell me about your site – I reply within 24 hours with an honest assessment and a fixed price.

Frequently asked questions

What are WordPress user roles?

WordPress user roles are named bundles of permissions (capabilities) that control what each account can do. Core ships five: administrator, editor, author, contributor and subscriber; WooCommerce adds shop manager and customer. Assigning the right role limits what a stolen or misused account can damage.

How many administrators should a WordPress site have?

Two: the person responsible for the site and the developer or maintenance provider. One is fragile if it gets locked out; three or more just multiplies phishing targets without adding recovery value.

What is the difference between an editor and an author?

An editor manages all content on the site – everyone’s posts, all pages, comments and categories. An author can only write, publish and delete their own posts and cannot touch pages or anyone else’s work.

What role should I give my client or site owner?

An administrator account for genuine admin moments, plus an editor account for daily work, with site-wide content exposed through friendly options pages. The client keeps full ownership; the account they use every day cannot break the site.

Can a WooCommerce shop manager install plugins?

No. A shop manager runs orders, products, coupons, customers and reports, but cannot install plugins, change WooCommerce settings, switch themes or edit site settings – which is exactly why staff should have it instead of administrator.

Should I disable the WordPress file editor?

Yes, on every site. Add define( 'DISALLOW_FILE_EDIT', true ); to wp-config.php so nobody – including a stolen administrator session – can edit theme or plugin PHP from the browser.

How often should I audit WordPress users?

Quarterly for most sites, and immediately whenever someone leaves the team. The audit takes about fifteen minutes: verify every administrator, remove stale and ex-staff accounts, check last logins and confirm registration defaults to subscriber.