Add the security warning to more core module permissions

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Research

I've taken a fresh look at existing 11.x restricted access permissions to get a sense of the existing categories where a permission has been considered worth this warning level.

Site building and maintenance

As somebody who builds sites for clients, this is all in the list of things I generally would not want them to be able to do for fear of breaking things, even unintentionally.

• administer [entity_type] types
• administer [entity_type] fields
• administer [major subsystem] (actions|site configuration|themes|views|workflows)
• translate interface
• administer text formats and filters
• export configuration
• import configuration
• synchronize configuration
• translate configuration
• administer software updates

However, I'm not sure that I could back up all of these as having "security implications" without being so broad as to then need to flag all of the administer [entity_type] display and administer [entity_type] form display permissions as well.

User management

It's important for site owners to be able to manage their own users, and having the warning messages here helps to reinforce how important it is that user roles and permissions are handled thoughtfully.

• administer account settings
• administer permissions
• administer users
• select account cancellation method

Access overrides

A webmaster or designated content administrator should be able to bypass access controls that are in place for users with lower levels of access.

• administer [entity_type] entities (usually "content" but implied in some cases)
• delete any file
• configure any layout
• bypass content access control
• link to any page
• bypass entity access own workspace

Information disclosure

Pages that provided detailed system information should be protected in order to prevent malicious actors from gaining information about the specific software version(s) used by the site, or to information disclosed in error logs.

• access site reports

Other notes

The permissions for individual filter formats now have a specific warning: "This permission may have security implications depending on how the text format is configured."

Proposal

Using the above as guidelines, here are the permissions I would suggest adding to the restricted list.

Access

• administer workspaces meets the "administer [entity_type] entities" criteria
• administer blocks meets the "administer [entity_type] entities" criteria
• administer comments meets the "administer [entity_type] entities" criteria
• administer contact forms meets the "administer [entity_type] entities" criteria
• view any unpublished content meets the "bypass access control" criteria
• ban IP addresses could arguably fall into this category as it could do the opposite -- prevent site owners from being able access their site completely

Information disclosure

• administer modules allows access to the module list page, which shows enabled versions
• view update notifications displays module versions and specifically highlights out-of-date modules