Can you explain how user roles and permissions impact security on my website?
Users, roles and permissions are key components of website security, and they're of major importance in Drupal as well. Users are the people, roles are their functions, and permissions define what authorizations those functions have. Setting these up incorrectly can compromise your website's security.
The best practices for securing your website's users, roles, and permissions are based on the following ideas:
Rethink your roles
When discussing website security, we often use words like attacker, malicious user, or untrusted to define website visitors who may be intending on abusing resources, stealing, or altering data. In Drupal, visitors can achieve these goals by using the permissions granted to their roles. The key point is to think of website visitors in terms of what roles they have and the permissions we've granted to those roles. Instead of just thinking about trusted versus untrusted users, we're thinking about trusted versus untrusted roles.
On your website, which roles are trusted and which are untrusted, and what permissions have you given to those roles? Which permissions have you granted to the Anonymous role (and thus to anonymous website visitors)? As you build and add features to your website, you're also widening the available points of attack. If you've allowed users to create accounts without administrator approval, you should also consider which permissions you've granted the Authenticated role — users with this role are allowed to sign in to your website. Is your website configured to allow authenticated users to create content or post comments without approval? Be sure that you can answer this question for your website's security.
Know the defaults
Community-contributed modules as a whole are less secure than Drupal core, and because of this, it's especially important to be cautious about elevated permissions created by contributed modules. Role management can be burdensome; however, some modules grant roles to users upon account creation. Know the defaults, because most Security Advisories for contributed modules crop up because of cross-site scripting (XSS) vulnerabilities . These often exist on module administration screens where user-supplied data is not properly filtered. Whenever possible, use the principle of least privilege and give roles only the permissions that they absolutely need.
Evaluate your elevated permissions
Certain permissions (such as User: Administer users and Filter: Administer text formats and filters) should never be made available to untrusted roles, because they can allow for full control of your website. Many of the permissions that should not be enabled for untrusted roles (such as Anonymous) have one or more of the following descriptions associated with them:
- Warning: Give to trusted roles only; this permission has security implications.
- Warning: This permission may have security implications depending on how the text format is configured.
Be aware that not all modules that should be disabled for untrusted users have a warning message. Examine the entire list of permissions to ensure that roles have only the permissions that they need, and nothing more.
When in doubt, follow the practice of removing the permission from a role — it's easier to add a permission later or create a new intermediate role than to restore your databases from backups and have to inform users of a security breach.