What Is The Principle of Least Privilege in WordPress
What Is The Principle of Least Privilege in WordPress
Computer programmers like to give things big names. This is how we end up with something called the “Principle of Least Privilege” (POLP) to say something as simple as only let users do what they absolutely need to do.
That’s all we are talking about here. Make sure that all the users in your site have exactly the permissions they need, and nothing more. But since that doesn’t sound impressive, we are going to call it POLP from now on.
Application Users
The easiest user to talk about is the WordPress application user.
- You probably have one or more administrator accounts.
- You may have multiple “Editor” or “Author” accounts.
- Depending on your site, you may also have “Subscribers”.
POLP teaches us that you should absolutely limit the people that have administrator privileges to those that need it and can prove that they need it. In most systems, this usually means you need a primary administrator and a backup administrator in case something happens to the primary like they forget their password the same day you find out your password recovery mechanism isn’t working. By the way, securing your logins as best as possible is an absolute must, so we strongly recommend you to check this article on how to set up a 2-factor authentication on your WordPress.
Anyone else who requests administrator privileges should have to prove that they can’t get their daily job done without them. Yes, it is inconvenient to have to ask someone to do something for you but limiting administrator accounts limits that damage that can accidentally be done to your system.
Editor and Authors have less opportunity to do damage so you don’t have to be quite as strict about them but even so, everyone who has privilege in the system should have a reason for having that privilege.
Database Users
The next “user” we need to discuss is your database user. Every WordPress site has a user and password it uses to access the database that runs WordPress. POLP teaches us that that user should have the least amount of privilege necessary to do the job.
Unfortunately, since plugins use this user to create and delete tables, data, etc. this user has to be pretty powerful. Still, this user does not need to be all-powerful. There are two important things to check on the user that you use to access your database. (If you do not know how to check these, hire a developer, this particular part is pretty technical).
- Your database user should not have GRANT privileges. This means that it cannot grant privileges to other users. There is no scenario in WordPress where the database user should be creating new users or granting them privileges to anything.
- Your database user should not have access to any database other than the one that is attached to your WordPress site. That user should not be able to access data or make modifications to ANY other database on the server.
If you are looking to implement some changes based on the above section, you can check the following tutorial and see how to manage user’s privileges in your MySQL database.
Access to Control Panels
Finally, premium hosting partners like SiteGround have very powerful control panels that let you control things orbiting your site like email and performance. Many of these controls can do serious damage to your site if used improperly or maliciously.
SiteGround and other hosting partners allow you to add “collaborators” to accounts. Collaborators make it very easy for someone to help solve problems or perform maintenance for the site owner. This is a much better way to allow a developer to help you than sharing your login and password. You can also check our article on how to secure your login details in 5 simple steps.
Review POLP Regularly
Whether it’s your WordPress users, or your Control Panel collaborators, you need to regularly review who has elevated access to your system. At the very minimum, once a month it is a good idea to review and evaluate users who have elevated access and make sure they still require this access. When they don’t, demote them or remove them altogether until such time as you need them to have that level again.
These audits won’t take much time but could save you many hours of disaster recovery if a forgotten account gets compromised and used to harm your site, not to mention the damage it will do to your online reputation.
Remember, reputation grows slowly like a coconut tree and falls quickly like a coconut.