Table of Contents 5 sections
What Are WordPress User Roles and Capabilities?
WordPress implements a role-based access control (RBAC) system that determines what each user is permitted to do within the WordPress administration environment. A role is a named collection of capabilities, and each user is assigned one or more roles that define their permissions. WordPress ships with six default roles: Super Admin (Multisite only), Administrator, Editor, Author, Contributor, and Subscriber. Each role is assigned a progressively narrower set of capabilities, from the Administrator who can perform virtually any action to the Subscriber who can only manage their own profile.
Capabilities are the atomic units of permission in WordPress. Each capability represents a specific action such as edit_posts, publish_posts, manage_options, install_plugins, or delete_users. WordPress core defines approximately 70 default capabilities, and plugins can register custom capabilities for their own functionality. When a user attempts to perform an action, WordPress checks whether their role includes the required capability using the current_user_can() function. This check is the fundamental authorisation mechanism in WordPress and must be implemented consistently across all administrative functions.
Default Roles and Their Security Implications
The Administrator role has the highest privilege level on a single-site installation, with capabilities including manage_options, install_plugins, install_themes, edit_theme_options, and delete_users. This role can modify any aspect of the site, making Administrator accounts the primary target for attackers. A compromised Administrator account grants complete control over the WordPress installation, including the ability to install malicious plugins, modify theme files, create additional admin accounts, and access or export all site data.
The Editor role can manage and publish content from any user, including editing and deleting published posts, but cannot modify site settings, install plugins, or manage users. Authors can publish and manage only their own posts, while Contributors can write and edit their own posts but cannot publish them. The Subscriber role has no content management capabilities and exists primarily for authenticated access to restricted content. Understanding these privilege levels is essential for applying the principle of least privilege: every user should be assigned the minimum role necessary for their responsibilities, reducing the potential impact of a compromised account.
Implementing Capability Checks
The current_user_can() function is the cornerstone of WordPress authorisation and must be called before any action that requires specific permissions. This function accepts a capability name and optional arguments (such as a post ID for object-level capabilities) and returns a boolean indicating whether the current user has the specified capability. Developers must use this function in every admin page, AJAX handler, REST API endpoint, and form processor to ensure that only authorised users can perform sensitive operations.
A critical security mistake is implementing visual restrictions (hiding menu items or buttons) without corresponding server-side capability checks. An attacker can bypass client-side restrictions by directly crafting HTTP requests to the underlying endpoints. Every server-side handler must independently verify the user's capabilities, regardless of what the front end displays. The pattern should be: verify the nonce (to prevent CSRF), verify the user's capability (to prevent unauthorised access), validate and sanitise input, perform the action, and return the result. Skipping any of these steps creates a security vulnerability.
Custom Roles and Capabilities
WordPress allows developers to create custom roles and capabilities to implement fine-grained access control tailored to specific business requirements. The add_role() function creates a new role with a specified set of capabilities, while add_cap() adds individual capabilities to existing roles. For example, an e-commerce plugin might create a "Shop Manager" role with capabilities to manage products and orders but not to install plugins or modify site settings. This granularity enables organisations to give each team member exactly the permissions they need and nothing more.
Custom capabilities should follow a consistent naming convention and be documented thoroughly. When a plugin is deactivated or deleted, it should clean up any custom roles and capabilities it created to avoid leaving orphaned permissions in the database. Developers should be cautious about granting powerful capabilities like unfiltered_html (which allows posting arbitrary HTML including JavaScript) or edit_files (which allows modifying PHP files through the dashboard) to custom roles, as these capabilities can be exploited to escalate privileges or execute arbitrary code.
Role and Capability Security Best Practices
The number of Administrator accounts on a WordPress site should be kept to an absolute minimum, ideally one or two. Every additional Administrator account is another high-value target for attackers. For day-to-day content management, even experienced team members should use Editor or Author accounts. Administrator accounts should be reserved for genuine administrative tasks like plugin management, site configuration, and security operations, and they should be protected with strong passwords and two-factor authentication.
Regular audits of user accounts and their roles help detect privilege creep, where users accumulate more permissions than they need over time, and identify dormant accounts that should be removed. Plugins that extend the role system should be audited to ensure they do not inadvertently grant excessive capabilities. The user_has_cap filter can be used to dynamically modify capabilities at runtime, which is powerful but should be used with extreme care as incorrect implementations can bypass the entire authorisation system. Logging all capability checks and their outcomes provides an audit trail that helps administrators investigate suspicious activity and verify that access controls are working as intended.
FAQ
Frequently Asked Questions
On a single site, the Administrator role has the highest privilege level with full control over all settings, plugins, themes, and users. On a Multisite network, the Super Admin role supersedes Administrators with network-wide control.
Assign each user the minimum role necessary for their responsibilities. Use the built-in roles (Subscriber, Contributor, Author, Editor) or create custom roles with specific capabilities using add_role() to implement fine-grained access control.
current_user_can() is the core WordPress authorisation function that checks whether the logged-in user has a specific capability. It must be called server-side before any action that requires permissions, regardless of front-end restrictions.
Tags
Related Definitions
What is the WordPress Database (wp_options, wp_posts)?
The WordPress database is a MySQL or MariaDB relational database that stores all site content, settings, user data, and plugin configurations in a structured set of tables, with wp_options and wp_posts being two of the most critical and security-sensitive tables.
What is the WordPress REST API?
The WordPress REST API is a JSON-based interface that allows external applications and front-end frameworks to interact with WordPress data over HTTP, enabling headless architectures and third-party integrations.
What is WordPress Cron (WP-Cron)?
WordPress Cron (WP-Cron) is a pseudo-cron system that schedules and executes time-based tasks such as publishing scheduled posts, checking for updates, and sending email notifications, triggered by site visits rather than system-level timers.
What is WordPress Hooks (Actions and Filters)?
WordPress hooks are a system of actions and filters that allow developers to modify or extend WordPress core functionality without editing core files, forming the backbone of the plugin and theme architecture.