Allow Xss::filter() to restrict allowed attributes

Created on 17 May 2025, 2 months ago

Problem/Motivation

A lot of contrib modules sanitize user inputs with Xss::filter(), either calling it directly or indirectly (#markup or #prefix) for example.
This method can be called with a list of allowed tags but it will always allow every attribute except a list of dangerous attributes (most notably on* attributes).

The CKE config allows specifying allowed attributes, we should have the same control when sanitizing outside of CKE fields.

This would help mitigate (although not completely prevent) XSS attacks where the attacker needs to insert a tag with a specific attribute in the page.
We have seen multiple XSS vulnerabilities that could not be exploited in CKE fields (because they required a specific attribute that's usually not allowed, for example a specific data attribute) but could be exploited when using a module that sanitizes user inputs with Xss::filter().

Steps to reproduce

Imagine a module that wants to allow some specific tags:

Xss::filter($userInput, ['a', 'b']);

The module knows it only cares about some very specific attributes (for example href) but has no way to restrict those.
While allowing other attributes is not dangerous by itself, it is always better to restrict what attackers can input and to use an allowlist rather than a blocklist.

Proposed resolution

I guess it does not make sense to separate the allowed attributes from the allowed tags.
But we could have something like this:

    Xss::filter($userInput,
      [
        // Allow any attribute.
        'b',
        // Allow specific attributes.
        'a' => ['href'],
        // Don't allow any attribute.
        'span' => []
      ]
    );

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

🐛 Bug report
Status

Active

Version

11.0 🔥

Component

render system

Created by

🇫🇷France prudloff Lille

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Production build 0.71.5 2024