Extensible Sanitizer

🚀 feature request

Relevant Package

@angular/core

this line and file are of key interest: https://github.com/angular/angular/blob/486cade596a57b7c146ae3aa269d69d7d828a6ab/packages/core/src/sanitization/html_sanitizer.ts#L95

Description

The ability to trust a custom whitelist of HTML tags, attributes, and values with a DOM sanitizer, without bypassing the whole sanitizer.

This would allow preservation of id, style, data attributes, and other common attributes. These attributes are useful in a variety of use cases for many Angular developers. This issue is a common cause of many GitHub issues, StackOverflow questions, and other indicators that there is a real problem with demand for a secure and flexible solution.

Related SO 1 Related SO 2 Tutorial on a best practice approach to doing what I am requesting this would close a bunch of github issues and resolve many SO questions.

Describe the solution you’d like

I would like to be able to specify three things to allow keys and values to be sanitized in a SecurityContext.HTML.

This could be implemented as an options argument to DomSanitizer.sanitize, or it could be implemented as a custom SecurityContext, but I will use options object in my description below:

    trustedFirstParagraph$ = this.translateService
        .translate('some-translation-key')
        .pipe(map(s => this.domSanitizer.sanitize(SecurityContext.HTML, s, options)));

Here, options can be an object with any of three keys:

const options = {
  trustAttributeKeyExpression: /some-regex-to-trust/,
  trustAttributeValueExpression: /some-value-to-trust/,
  trustAttribute: (el, key, value): boolean | string[] => {
      // arbitrary logic that can return a boolean
      // or [string, string] sanitized/transformed [key, value].
  }
}

trustAttributeKeyExpression and trustAttributeValueExpression must both match if both are specified. To implement an OR operation, and other more complex algorithms, a developer can use trustAttribute.

Describe alternatives you’ve considered

1. hiding data inside the class attribute and parsing it
2. using a span or div inside my element which is visually hidden but which I can access through my component dom ref and parse out the value
3. de-DRYing my code and having component-specific content across n components instead of being able to leverage a generic service

[Ruud-cb]

Please put this a bit higher on the to-do list, top-listed stackoverflow questions suggest using bypassSecurityTrustHtml as a solution! Thus leaving a lot of applications open for XSS attacks…

[RichardMcSorley]

Agreed this would be a much need feature. I’m unable to use data attributes for my markdown to HTML project. So without this I’m blocked.