/token/tree route missing proper access permission

I’m adding a different permission. It seems this should be configurable via site builders, so the solution should be based on a different approach, rather than adding this type of permission (Drupal role-based permissions).

Changing this to the "security improvements" tag as the underlying functionality is protected by CSRF.

The two suggested changes might work for some sites, but wouldn't necessarily work for all, due to how the token browser can be made available in specific places that aren't locked down to only admins, e.g. in the Metatag field on content.

Hmm, I'd like to think on this one, what the impact is, and to move carefully with this. I definitely intended for the user of the token link to use the appropriate access control for their uses. This feels like an API, use responsibly.

I feel like I can think of valid scenarios that this could break functionality on existing sites where the token tree link might be on a front-end and not only on the backend (although they are a wide majority of use cases).

Yes, this has been reported as a security issue before 3 years ago, but I could never reproduce it there and it was closed. damienmckenna, you were in that one too.

Can you provide steps how an anonymous user without a token tree link displayed on the site (at which points it is kind of a deliberate decision to expose it I guess) can access this?

Tokens can be available to most users, in theory even anonymous, although that's probably pretty uncommon and risky even. An administrative permission is definitely not going to work.

I had Claude look into this issue and got,

My read: berdir's skepticism is well-founded from what I see in the code — there's no path to a valid CSRF token without the link being rendered somewhere the anonymous user could reach, and rendering that link to anonymous users is often intentional (front-end forms with token support). So this isn't a bypass of access control so much as "the token tree inherits the visibility of wherever it's linked from," which is arguably by design. A real fix likely needs a new permission (e.g. access token tree) with a sensible default (probably granted broadly, maybe even to anonymous, to preserve existing sites) that site builders can restrict — not a hardcoded admin-only gate, matching andreadruiz's original instinct rather than sabrina.liman's patch.

@berdir, should I add an "access token tree" permission on this fork, or does that feel unnecessary?