Applying the principle of least privilege for improved WordPress security
The principle of least privilege for WordPress misses out on the big headlines when breaches, data loss and DoS attacks occur. Yet it is one of the most effective, if overlooked, security best practices for WordPress websites.
In this blog post, we first define the principle of least privilege, then examine when and where it applies, the risks of not adopting it, and why many website developers still are not building it into their WordPress websites. We also share some practical recommendations, so that you can immediately begin to improve the security of your WordPress websites. This blog post includes a few mini case studies to help illustrate its use in real settings.
Table of contents
What is the Principle of Least Privilege?
The idea is very simple: do not grant a user account, process or program more access rights than it needs to accomplish its designated tasks. In terms of a typical WordPress website with a blog, think of your editors, authors, contributors and subscribers. Each of them needs access to more or less of your website’s backend.
The principle of least privilege (PoLP) is also known as the ‘principle of least authority’, the ‘principle of minimal privileges’ or the ‘least privileged user account’ (LUA).
Let’s consider some simple examples. Your toddlers do not often need access to the kitchen. So, you fit an access control device, such as a safety gate, at various points through your home to enable them to wander at will – except for certain rooms. In a shared, public coworking space, you’d log off your laptop before leaving for lunch. And, your fancy restaurant’s parking attendant will require your ID or ticket before handing back the keys to your car. Access control prevents damage to you and your users’ valued property – whether it’s a physical item or digital collateral.
When and where does the Principle of Least Privilege apply?
The simple answer is that it applies everywhere: from that toddler who wants to climb the stairs to the users on your WordPress website hosting account. Your finance freelancer who needs to download the monthly invoices does not need the same level of access as the website administrator. The same goes for all sorts of privileged company accounts, file management systems, marketing strategy documentation or password managers.
What are the risks if PoLP is not applied?
Controlling access to certain areas seems a no-brainer. Otherwise, aren’t you leaving the website entirely at the whim of any logged-in user – including those who may make innocent and inadvertent mistakes, and may not even be aware they’ve made them, nor of the unintended outcomes?
Think of the following possible users:
- New user starts with little understanding of the business implications of mistakes on a WordPress website
- Those with little WordPress administration experience
- With no knowledge of the implications of downloading new WordPress versions or plugins at will, or of updating them without first making a backup
- Those with limited security awareness creating new users or changing permissions of existing users
- Those who don’t know how to deal with reported errors or other problems
- External blog post contributors such as partners, freelancers and clients, with perhaps a smattering of WordPress knowledge, who may even ‘helpfully’ download or update plugins on your website – without asking
It also means your entire WordPress backend is at risk of some otherwise unauthorized person, such as someone with inappropriate levels of access, adding new users and giving them access to areas of the website where they can cause deliberate harm.
- Altering themes, customized features or public-facing website content
- Mishandling stock, SKUs or product metadata on e-commerce stores
- Offering unauthorized discounts
- Accessing, changing, downloading or deleting code, page templates, media, configurations, or staff, customer and other types of files
- Accessing company, customer, health or financial data, for example, to misuse or sell to other nefarious parties
- Taking the site and its products or services offline
Whether you use WordPress or not, any or all of these problems can occur when the principle of least privilege for WordPress is not adopted deliberately and consistently throughout your organization.
TIP: Use an activity log plugin for WordPress to keep a log of all the changes that users do on your WordPress website. It helps with user accountability and eases troubleshooting.
Why do many website owners neglect the principle of least privilege in WordPress?
The risks we’ve outlined seem pretty persuasive, right? But one of the most common problems reported following WordPress website audits is that WordPress users’ roles in a typical environment are still configured as follows:
- The WordPress administrator role is given to every user, even when the user just needs to input content written by someone else
- The same applies to files and directory permissions, all of which are configured with the least restrictive permissions
We get it. We’ve all had experience working as system and website administrators at some point in our careers. Rather than liaising between users and permissions in the early days, checking what the user needs to do, administrators often prefer to simply assign them the administrator role too (it seems quicker, initially).
The same applies to files and directory permissions. For example, some WordPress plugins store cache files or other data on the file system (i.e. in the WordPress directories). It is easier to simply configure 777 permissions in the /wp-content/plugins/ directory, because all plugins will work and it’s not necessary to spend further time troubleshooting and tweaking permissions each time you install a new plugin. But, conducting some research at the beginning to determine the specific areas of the website application or directories – to prevent users from having too much access – reduces the risks already mentioned. And, it has the added benefit of enabling everyone to gain access to what they need to do their job – without further input from an administrator.
Questions that website owners and administrators musk ask
Is convenience worth the security risk? You know what our answer to that question would be. There is simply no point installing and maintaining upfront and robust web application security plugins, password protocols and other measures such as 2FA, if your greatest security risk is that you’ve already left the back door propped open with amateur and lax access controls!
How to apply the principle of least privilege for WordPress
Now that you’re focused on making your website application the most secure it can be, this section provides you with a list of where and how the principle of least privilege can be applied to a WordPress website or blog.
WordPress database user privileges
Let’s start with the most basic place – WordPress user database permissions or privileges.
For normal daily WordPress operations such as writing and publishing of content, the WordPress database user only needs the following permissions to enable them to manage the data from within the database:
These permissions do not allow the WordPress database user to modify the database structure.
In an ideal environment, to harden the security of your WordPress website or blog, you should configure secure and restrictive WordPress MySQL database privileges. Only revert to assigning all privileges to users who need to install a new plugin that creates new tables in the database, or when WordPress has been updated and there are changes to the WordPress database schema.
Another recommendation is to avoid granting access to databases other than the WordPress one for the relevant website.
For more information on WordPress database privileges, you can also read Why minimum MySQL user WordPress database privileges improve security, which explains the repercussions of insecure configuration.
WordPress users roles and privileges
WordPress users make mistakes – even administrators. And, users also like to explore settings and configurations. If you assign users Super Admin or Administrator access, the more curious among them will most likely install random plugins. This can potentially result in an unintentional change in user experience, such as a change in the website’s functionality.
WordPress has a number of built-in user roles and connected capabilities, as listed below (from most to least).
- Super Admin – site network admin
- Administrator – site network admin for a single site
- Editor – manage and publish posts, including posts of other users
- Author – manage and publish own posts
- Contributor – write and manage own posts, but not publish them
- Subscriber – manage profile only
An example of how this works in practice is that while a Contributor and Author may share some capabilities (e.g. edit posts and delete posts), a Contributor is unable to do everything an Author can, such as upload files or create usable blocks.
Creating custom roles
There are also a good number of plugins that you can use to create new and custom WordPress roles.
Here are some common use cases:
- In larger organizations, you may need to assign someone in your marketing team to moderate, approve and reply to comments. The ‘moderate comments’ capability is housed within the Editor role, but this role also assigns a whole host of other powerful capabilities. So, if that is all they need to be able to do, then setting up a custom role, with this single permission, is sufficient.
- If your WordPress site contains an e-commerce plugin such as WooCommerce, you’re limited to two initial roles: Shop Manager (allowing the user to manage the entire store) and Customer (allowing the user to view their account and orders). The Administrator has additional permissions, such as ‘manage settings’ and ‘view reports’. But, what if your users – non-management staff, for example – require something in between, such as the ability to add and manage stock quantities or SKUs, or just process orders?
- On our website, we use a plugin for our knowledge base articles. This gives our support team access to create and modify knowledge base articles, but no access to the main website pages and blog posts.
For most regular users, the Contributor role is sufficient. For team leaders and hands-on managers, the Editor role is advised. But, you should restrict the Super Admin and Administrator roles to experienced, responsible users who really need them.
For more information, see How to use WordPress user roles for improved WordPress security.
Files and directories permissions
It is easy to configure file and directory permissions and there is ample documentation available online explaining how to harden the permissions of your WordPress installation. WordPress runs on any OS that runs PHP, commonly Linux. In terms of groups, Linux has three permission groups:
- Owner – owner of the file/directory, whose permissions neither apply to nor affect any other users
- Group – group of users that have been assigned access to file/directory, whose permissions neither apply to nor affect any users outside the group
- Other – what permissions levels everyone else has to the same file/directory
The implication of assigning the wrong permissions to the wrong permission group could mean that a malicious hacker could take advantage and result in a low level vulnerability spiralling into an unacceptable risk.
When installing WordPress, you should also use the PoLP, configuring the least possible file and directory permissions for WordPress to work.
Remember that by hardening the file and directory permissions, you might also restrict some WordPress plugins from functioning. As explained earlier, you might be installing plugins that need to store data in their installation directory. If so, do not simply configure 777 permissions to the plugin directory (full read, write and execute to anyone with permissions to control it). That is the easy way out. But you should also avoid limiting it so far that it prevents the relevant users from updating WordPress, its themes and plugins from the web UI.
For further information, see WordPress file permissions: the guide to configuring secure website & web server permissions.
WordPress plugins configuration
Not all administrators are equal. Like many systems and networks, it’s common to have a lead admin among a group of WordPress administrators. Typically, the owner of the website has no other option but to assign other users admin access. Bear in mind that in the case of WordPress security plugins, they often can store sensitive data, such as a WordPress security audit log, to which admins would have access.
WordPress security plugins usually allow you to restrict access to other WordPress administrators. Making use of such features seems like a small, but sometimes overlooked, control that will help you keep in better charge of user access.
For more information on individual plugins, contact the plugin support and hosting provider. Then ask which directories the plugin needs to write to, so you can configure permissions specifically for that directory.
FTP access for third party contractors
When you hire a designer, or a plugin’s support team needs FTP access to your website, you might grant them full access to the root of your website, right? This is unnecessary.
In the case of a designer, all they need access to is the theme’s directory, so restrict access to that directory. The same applies to plugin support teams. If they need access to check log files, give them FTP access to the plugin’s directory or to the location where the plugin stores the log files. Avoid depending on external parties to do the security due diligence for you.
Mini case studies
Let’s look at some relatable examples of how this works in practice, and how access control questions and decisions can drive the application of PoLP to enable the right access for the right teams and individuals.
E-commerce website applications
E-commerce website applications, such as those where consumers purchase big ticket items like fridge-freezers, vacuum cleaners, cameras or laptops, offer various examples of where PoLP can be adopted.
Some of the access control decisions for e-commerce website application developers are obvious:
- HR departments probably won’t need access to customer data, or file directories that store plugins, but they will need access to the majority of the staff records (though perhaps health data, which often enjoys special status under many data protection compliance legislation, may be more restricted to a need to know basis)
- Marketing departments won’t necessarily need access to SKU tables or product codes. However, they’ll want access to tables in the product database that list product names, specifications and descriptions
Some are less obvious:
- Do consumers need access to all their data all the time?
- Do PCI-DSS compliance officers need access to all the consumer data?
Universities and educational institutions
What about the more traditional and long-standing institutions, where web application security and PoLP is initially less apparent?
Some of the access control decisions for university and college portals are obvious:
- Payroll department need access to staff and contractor records in the website application to track working days and make payments
- Administrative departments of various types may need access to student records, to process IDs, accommodation applications, bills, or grants
Some are less obvious:
- What third party suppliers, such as building swipe card providers, might need intermittent access to some student data tables?
News websites and blogs
The web is full of news websites, podcasts and blogs. Many website owners depend on multiple administrators, contributors, editors, proofreaders and publishers. In addition, there are subscribers and viewers to consider.
Some of the access control decisions for news and blog website applications are obvious:
- Depending on business areas of responsibility, editors may need access to a combination of everyone’s pages, articles and blog posts
- Contributors will need access to just their own blog posts
Some are less obvious:
- Do all third parties need access to every table in the WordPress database? This is where customized controls come into their own.
Our final example is something that many of us use on a daily basis, banking website services. Aside from health information, personal financial data is naturally one of the most confidential types there is.
Some of the access control decisions for making website applications are obvious:
- No banking service user should have access to another user’s account, except by express (probably user-controlled) consent
- Staff user accounts should have access to many service user accounts, but limited only to those tasks they need to perform as part of their job
Some are less obvious:
- How much access should technical support departments have? Should they be able to view and amend everything, in case of errors?
We recommend that you think and plan out the business use case for each scenario. In conjunction with your groups of users and individuals with unique job descriptions. Map out these first. Only then can you begin to examine the access control protocols available to you in your WordPress website.
Health and fitness trackers
Health or fitness tracker devices and their connected online dashboards collect, store and share fascinating statistics about users and their health data, activity, targets and achievements.
Some of the access control decisions for the health and fitness tracker brands are obvious:
- Which teams inside the organization need access to which data? It makes sense that if one team is responsible for the design and development of the sleep tracking part of the app, that they do not necessarily need access to the workout statistics tables.
- Most users will want the PoLP (whether they know about it or not) to be very restrictive, so their health information is not shared with every other user. So, what access privileges should be given to the normal user role, and what data will therefore be shared on a public profile (name, profile image and average daily steps only?).
Some are less obvious:
- What, and how much, information needs to be accessible to other users to facilitate the common gamification features of such tools?
- Should the developers set all access permissions, or should some of this decision-making be offloaded to users?
Using the Principle of Least Privilege for WordPress and beyond
The above is only a selection of the most common scenarios where the principle of least privilege for WordPress is often overlooked but can be easily applied.
In order to start adopting PoLP, begin by considering what you want to do about the following items:
- The web server
- The database
Don’t shy away from applying the principle of least privilege simply because things don’t work out straight away. Yes, most of the time you have to spend a few hours configuring customized user roles and troubleshooting plugins. Repackage this in your mind as a long-term investment in the security of your WordPress websites.
The post Applying the principle of least privilege for improved WordPress security appeared first on WP White Security.
*** This is a Security Bloggers Network syndicated blog from WP White Security authored by Dawn Baird. Read the original post at: https://www.wpwhitesecurity.com/wordpress-security-principle-of-least-privileges/