Contrib.social

Provide warning when trying to use dangerous HTML markup

Open on Drupal.org →
Created on 13 August 2017, almost 8 years ago
Updated 29 May 2025, 2 months ago

Problem/Motivation

There are some HTML tags that the security team considers dangerous, and we should provide feedback for site administrators and site builders when they choose to enable these tags in text formats. For instance the HTML tags not allowed by filter_xss_admin() should be considered dangerous.

See https://www.drupal.org/node/224921 → for a list of tags.

The following people have contributed to this issue: drumm, mlhess, stefan_r, David Rothstein, greggles, YesCT, cashwilliams

Proposed resolution

The list of tags needs more thorough review before proceeding with the issue per @alexpott in #36.

Provide feedback to users who try to add these HTML tags to the filtered HTML input filter. These HTML tags should match those not allowed by filter_xss_admin(). We can also link to and review the documentation page, Configuring text formats (aka input formats) for security → .

Remaining tasks

  • Write a patch with tests
  • Review patch considering language used and markup changes

User interface changes

Yes. There is new proposed language and text for site administrators.

API changes

No.

Data model changes

No.

✨ Feature request
Status

Needs work

Version

11.0 🔥

Component

filter.module

Created by

🇺🇸United States mradcliffe USA

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

    It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.

  • Needs backport to D7

    After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • First commit to issue fork.
  • Merge request !12271Apply patch from comment 39 → (Open) created by prudloff
  • Pipeline finished with Failed
    2 months ago
    Total: 222s
    #509770
  • Pipeline finished with Canceled
    2 months ago
    Total: 105s
    #509777
  • Pipeline finished with Failed
    2 months ago
    Total: 228s
    #509778
  • Pipeline finished with Canceled
    2 months ago
    Total: 701s
    #509781
  • Pipeline finished with Failed
    2 months ago
    Total: 404s
    #509789
  • Pipeline finished with Success
    2 months ago
    Total: 732s
    #509798
  • Comment 2 months ago →
    🇫🇷France prudloff Lille

    As alexpott said we filter dangerous attributes so most tags that would be dangerous otherwise are not.
    However we can't guarantee that we remove dangerous attributes for every possible tag (for example we didn't remove srcdoc attributes on iframe until 🐛 Remove srcdoc attributes in Xss::filter() Active ).

    So in order to keep this simple and not duplicate the list of safe tags, I think we should display the warning when allowing tags that are not in filterAdmin().
    This does not mean that any additional tag would be dangerous, but that it could be because our XSS filter might not remove some attribute that could be dangerous on this specific tag.

  • Comment about 2 months ago →
    🇫🇷France prudloff Lille
  • Status changed to Needs review 5 days ago
  • Comment 5 days ago →
    🇺🇸United States dcam

    The proposed resolution only states the vague goal to "Provide feedback..." about unsecure tags. If implemented this feedback would only be provided when the format is saved. So on multi-admin sites only one person gets that feedback and only after saving the filter's form. What about the rest of the time, for instance when a format is imported from configuration? I don't see any discussion about when or where the feedback should be displayed. If this information is important for the site's security then shouldn't we display it every time the format is viewed or on the site status report? I'm tagging the issue for subsystem maintainer review to get comments on this.

  • Comment 5 days ago →
    🇺🇸United States dcam

    Escalating to the framework managers since Filter doesn't have a subsystem maintainer.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024