Problem/Motivation

The Media Library views provided by Drupal core are based on the "View media" permission, which can be granted to various roles. However, access to the displays within the views is restricted via additional runtime logic that Xray does not detect. As a result, Xray reports these views as publicly accessible when they are not, leading to false positives in security audits.

Steps to reproduce

  1. Install and enable the Media Library module (part of Drupal core).
  2. Ensure that the "View media" permission is granted to the anonymous user.
  3. Enable and run the Xray module.
  4. Observe that Xray reports the Media Library views as visible to anonymous users.
  5. Try to visit the Media Library route as an anonymous user: it will not be accessible due to extra access logic.

Proposed resolution

  • Enhance Xray's detection logic to account for runtime access checks beyond the base permission declared in the view.
  • If full detection is not feasible, allow for configurable or pluggable exceptions for specific views or routes that implement custom access logic.
  • Optionally, detect common patterns (e.g., custom access callbacks, `hook_view_access_alter`, or access plugins) that override default view accessibility.

Remaining tasks

  • Confirm whether the current Media Library access logic can be reliably detected.
  • Evaluate the feasibility of a generic approach for identifying custom access control in views.
  • Implement the proposed enhancement or provide a mechanism to declare view-specific exceptions.
  • Add tests to validate that views with runtime access control are not falsely flagged.

User interface changes

None expected, unless an exception list or UI feedback is added to the Xray module.

API changes

None.

Data model changes

None.

Issue fork xray_audit-3523561

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

juanjol created an issue. See original summary.

juanjol’s picture

Issue summary: View changes

juanjol’s picture

Status: Active » Needs review
juanjol’s picture

I've created a Merge Request that enhances how anonymous user access is checked for views. Previously, it only evaluated access via the display's access() method. Now, if a view display has an associated route, the MR also verifies anonymous user access to that specific route. This allows for the proper execution of route-related hooks and other access-blocking mechanisms (e.g., those used by the Media Library module's widget), ensuring more comprehensive access control.

lpeidro’s picture

I have changed the dev branch (2.x.dev)

lpeidro’s picture

Version: 1.x-dev » 2.x-dev
lpeidro’s picture

Status: Needs review » Fixed

Hello Juanjo, the implementation works as expected.

Thank yoy very mucah for your effort.

I merge the PR.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • lpeidro committed 6d7d78d7 on 2.x authored by juanjol
    Issue #3523561: Check views access for anonymouse user by route too
    

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.