WordPress user roles and permissions security

What WordPress roles actually mean

WordPress uses roles as named bundles of capabilities. The official roles and capabilities documentation defines the default roles as Super Admin, Administrator, Editor, Author, Contributor, and Subscriber. Each one is allowed to perform a different set of tasks.

The important part is that roles are not a corporate hierarchy. An Editor is not a "junior Administrator." It is a content role. An Author is not a "junior Editor." It is a role for someone who publishes and manages their own posts. The permission model is task-based, and your audit should be task-based too.

• Super Admin: controls a multisite network and all network-level features.
• Administrator: controls one site, including settings, plugins, themes, and users.
• Editor: publishes and manages posts, including posts by other users.
• Author: publishes and manages their own posts.
• Contributor: writes and manages their own drafts but cannot publish.
• Subscriber: logs in and manages only their profile.

Most permission mistakes happen when a site owner uses Administrator as a convenience role. A freelancer needs to edit a landing page, so they get Administrator. A writer needs to upload media, so they get Administrator. A support vendor needs one setting, so they get Administrator. Over time, the site accumulates a large blast radius.

The least-privilege rule

Least privilege means each account gets the minimum access required to do its current job. Not the job it had last year. Not the job it may need someday. Its current job.

That sounds obvious, but it changes how you manage WordPress:

1. Give access for the task, not for the person.
2. Prefer temporary elevation over permanent Administrator access.
3. Use separate accounts for separate people. Shared accounts destroy accountability.
4. Remove access when a project ends instead of waiting for a quarterly cleanup.
5. Require 2FA for any role that can affect money, code, content integrity, or customer data.

A small blog may only need one Administrator and a few Authors. A WooCommerce store may need shop managers, support staff, fulfillment accounts, and developers. The exact map changes by site, but the principle is the same: every permission should have a reason you can defend.

Capabilities that deserve extra scrutiny

Capabilities are the real permissions underneath roles. The WordPress developer documentation is clear that roles and capabilities are how WordPress controls user privileges. When you review access, look for these capabilities first:

• manage_options: site settings, many plugin settings, and often access to sensitive configuration.
• install_plugins, activate_plugins, edit_plugins: direct route to arbitrary PHP execution if abused.
• install_themes, edit_themes: similar code-execution risk through theme files.
• edit_users, create_users, promote_users, delete_users: account takeover and privilege escalation risk.
• unfiltered_html: allows HTML and JavaScript that would normally be stripped, risky for untrusted users.
• upload_files: necessary for content teams, but risky when upload restrictions or MIME validation are weak.
• manage_woocommerce or store-management capabilities: access to orders, customers, refunds, and commerce settings.

If a role has one of these capabilities, it should have a named business reason. "The plugin added it" is not a reason. It is an audit trail.

How to audit Administrator accounts

Start with the Administrator list because it has the biggest blast radius. In WordPress, an Administrator on a single-site install has access to essentially every administration feature. If that account is compromised, the attacker can install a plugin, add a new admin, change settings, edit themes, and persist.

1. Export the current user list. Include username, email, role, last login, 2FA status, and application password count if your security plugin tracks it.
2. Classify every Administrator. Owner, developer, agency, employee, service account, emergency account, unknown.
3. Remove unknown accounts immediately. If nobody owns it, it should not be Administrator.
4. Downgrade convenience admins. Content people usually need Editor. Writers need Author. Support teams often need plugin-specific support roles.
5. Require 2FA and unique passwords. No exception for "temporary" accounts. Temporary accounts are exactly the ones people forget.
6. Review recent activity. A stale admin that logged in yesterday after two years of silence is not just stale. It is suspicious.

For most small business sites, two or three Administrators is already plenty: the owner, the primary technical maintainer, and a break-glass account stored securely. More than that should trigger a review.

Recommended roles by job

Use this as a starting point, then adjust for plugins and business workflows:

• Site owner: Administrator, with 2FA and backup codes stored in a business password vault.
• Developer: temporary Administrator during active work; downgraded or removed afterward.
• Agency project manager: Editor or a custom project role, not Administrator by default.
• SEO specialist: Editor plus SEO plugin permissions if needed; avoid plugin install rights.
• Writer: Author if they publish their own posts; Contributor if content needs review.
• Editorial lead: Editor.
• WooCommerce support: Shop Manager or a narrower custom role.
• Customer or member: Subscriber or membership-plugin role with no admin capabilities.

The pattern is simple: code and settings access are Administrator-level. Content access is Editor/Author-level. Store operations should use store-specific roles. Membership access should never inherit admin capabilities unless the plugin explicitly requires it and you understand why.

Custom roles and membership plugins

Custom roles are useful, especially for WooCommerce, LMS, membership, and editorial workflows. They are also where permission drift hides. A role named "SEO Manager" might be harmless, or it might include manage_options because a plugin vendor took a shortcut.

When reviewing custom roles, inspect capabilities instead of trusting the label. Ask three questions:

1. Can this role change code, plugins, themes, or global settings?
2. Can this role create, promote, or delete users?
3. Can this role access customer, order, member, or private content data?

If the answer is yes, the role needs 2FA, a tighter owner list, and a written reason. If the role belongs to a plugin you no longer use, remove it after testing in staging.

Offboarding, service accounts, and 2FA

Offboarding is where good permission models usually fail. A developer leaves, an agency contract ends, or an employee changes jobs, and the account remains active because nobody owns the cleanup.

Set a simple operating rule:

• Remove human accounts the same day access is no longer needed.
• Disable shared accounts; replace them with named accounts.
• For service accounts, use descriptive names and narrow capabilities.
• Rotate application passwords and API tokens when a vendor changes.
• Review privileged accounts monthly on active ecommerce and membership sites.

Every privileged account should have 2FA. Every service credential should be scoped and documented. Every user should be tied to a person, team, vendor, or integration you can identify in minutes.

How Lockora audits permissions

Lockora reads the WordPress role and capability map, then looks for the risky combinations humans miss: too many Administrators, inactive privileged accounts, roles with manage_options outside the normal admin set, users with application passwords, public usernames on high-privilege accounts, and missing 2FA coverage where the site exposes it.

The report does not just say "review users." It points at the specific accounts and capabilities that create risk, then groups them by likely fix: downgrade, delete, require 2FA, rotate credentials, or investigate activity.

Common questions

How many Administrators should a WordPress site have?

As few as the business can defend. For a small site, one owner, one technical maintainer, and one break-glass account is usually enough. Ecommerce and agency-managed sites may need more, but every Administrator should have a named reason.

Is Editor safe for writers?

Editor is powerful because it can manage posts by other users. Use Author for writers who only need to publish their own content, and Contributor when content must be reviewed before publication.

Are custom roles risky?

Custom roles are not risky by themselves. They become risky when broad capabilities like manage_options, edit_plugins, or user-management capabilities are added without review.