Roles and the Principle of Least Privilege in WordPress

What Is the Principle of Least Privilege?

The principle of least privilege limits the impact of a compromised account. If an author's account is breached, an attacker may gain access to the content that author is allowed to create or edit, but should not automatically gain control over plugins, the theme, or other users.

This does not replace strong passwords, multi-factor authentication, updates, or backups. However, even if a password is stolen, a restricted role makes it more difficult to expand the attack.

Permissions should be reviewed not only when a website is launched. Employees change responsibilities, contractors finish their work, and plugins may add their own capabilities or alter the access model.

• Give users the minimum role required for their day-to-day work.
• Perform technical operations through a separate account.
• Limit temporary contractors' access by duration and task.
• Review permissions periodically and revoke them when they are no longer needed.

Which Role Should You Choose for Content Work?

In WordPress, a role defines a user's set of capabilities. Choose a role based on actual tasks, not job title or convenience. An administrator is not required for most editorial workflows.

An Author usually works with their own content: they create and publish posts and edit them within the available capabilities. An Editor has broader content access and can manage material created by other authors. This role is suitable for the person responsible for the site's editorial work, but it should not automatically include permission to configure the system.

A Contributor can prepare content without publishing it independently. A Subscriber has minimal permissions and is generally needed only for websites with account, commenting, or restricted-content features.

An Administrator can change system settings and manage users, themes, and plugins. This role should be limited to a small number of trusted people and should not be used as the default for everyday editing.

• A content manager most often needs only the Author or Editor role.
• A developer does not necessarily need to work constantly under the main administrator account.
• Define the role based on the content type, publication statuses, and access to media files.
• On WordPress Multisite, account separately for the Super Administrator role: it has significantly broader permissions across the site network.

A Separate Account for Technical Work

A practical approach is to maintain a personal account with a restricted role for everyday work and a separate, protected administrator account for updates, plugin configuration, and emergency actions. Do not use the administrator profile to write articles, check email, or perform other routine operations.

This separation reduces risk: if the password for a daily-use account is stolen through phishing or an infected device, the attacker will not immediately obtain system privileges. The administrator account should have a unique password, multi-factor authentication, and should not be shared by multiple people.

How to Audit WordPress Users

Start with a complete list of accounts in the WordPress dashboard. For each user, record the purpose, responsible person, role, and ongoing need for access. Do not rely on the name alone: verify the email address and confirm that the account actually belongs to a team member.

Unknown accounts, duplicates, test profiles, and former employees' accounts create unnecessary entry points. Before deleting a user, check their posts and choose whom to assign authorship to if necessary. For a contractor who no longer works on the website, revoke access rather than leaving the profile active just in case.

Do not use shared logins such as editor or agency. With a shared account, it is impossible to reliably determine who changed a page, created a user, or installed a plugin. Personal accounts improve auditing and simplify incident response.

• After reviewing related content, delete unknown and inactive accounts.
• Reduce users' roles when they no longer need administrative capabilities.
• Check for multiple accounts with identical or similar names.
• Change access permissions when an employee leaves or a contractor's work ends.
• Review login records and suspicious activity if this feature is available in your security system or hosting environment.

Elementor and Add-ons: Why the Standard Role May Not Be Enough

Elementor and its add-ons may have their own access settings or create additional capabilities within the editor. For example, an editor may be able to access templates, global styles, site settings, or other features that go beyond ordinary page editing.

The specific set of options depends on the Elementor version, active extensions, and site configuration. Therefore, you cannot assume that the Editor role automatically provides safe access restrictions. After installing a new add-on, check which capabilities it adds and who can use them.

For the editorial team, retain only the features needed to prepare and update pages. Access to global settings, templates, system widgets, and changes affecting the entire site should be limited to a small group of technical users.

Also check whether add-ons allow arbitrary HTML, JavaScript, or other code to be inserted. These capabilities should be available only to trusted administrators and used under a review procedure.

• Review Elementor permissions for each working role after configuration changes.
• Do not give editors global settings merely to make their work easier.
• Remove unused add-ons: every active extension increases the attack surface.
• Test restrictions with a separate user profile, not an administrator account.
• After updating Elementor or an add-on, check the available capabilities again.

Access to Hosting, the Server, and the Database

Restricting WordPress roles does not protect against excessive infrastructure-level access. Anyone with access to the hosting panel, SSH, SFTP, the database, or backups can modify website files regardless of their WordPress role.

Server access should be separated by task. A content manager does not need SSH keys, database access, or permission to modify files. For a contractor performing technical work, it is better to provide personal, temporary access and revoke it after the work is completed.

Do not send passwords in chats or store them in unencrypted text files. Use a password manager, personal accounts, multi-factor authentication where available, and separate keys for server access. Backups must also be protected: they may contain the database, configuration, and personal data.

• Separate access to WordPress, hosting, SSH, SFTP, the database, and backup systems.
• Do not use the same password for the admin panel, email, and hosting.
• Grant server permissions only to people who need them for a specific operation.
• After work is completed, revoke temporary access and replace shared keys.
• Regularly check who has access to the hosting panel and backups.

Common Mistakes and a Review Plan

The most common mistake is giving everyone administrator access to avoid spending time explaining restrictions. This is convenient only until the first account is compromised or a system setting is changed by accident. Another problem is leaving elevated permissions in place after a project ends or allowing plugins to create their own exceptions without review.

Test access changes on a staging copy or during an agreed maintenance window. After changing a role, ask the user to perform typical operations: create a draft, upload an image, and edit a page. At the same time, verify that they cannot see or change anything outside their responsibilities.

• Create an inventory of all users and system access.
• For each type of access, record its purpose, owner, and next review date.
• Check WordPress roles, Elementor permissions, and the capabilities of active add-ons.
• Separately review access to hosting, SSH, SFTP, the database, and backups.
• Enable multi-factor authentication for administrators and all critical services.
• After a suspicious login, immediately revoke the compromised access, change related passwords, and check new users, plugins, and activity logs.

What Not to Do

Do not rely solely on hiding menu items: if a user actually has the capability, visual hiding is not reliable protection. Do not leave administrator access enabled for all employees or create one account for an agency. Also, do not install role-management plugins without checking their source, maintenance status, and impact on permissions.