Should Dom Sanitization allow Angular Elements?

I’m submitting a…

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:

Current behavior

Angular Elements are great for creating standalone units, capable of running in a non Angular context.

This use case is great, but I also think it makes sense to run Angular Elements inside regular Angular applications. IMO, the main advantage is the ability to add Angular content to the DOM dynamically at runtime. An example use case is some form of a content publishing system with highly configurable UI.

The fact that Angular Elements can inherit the injector from the parent Angular app makes this super flexible. In addition to more dynamic DOM, it also opens the door to lazy loading of the Javascript backing the element (without the restriction of routing).

Previously this was very hard since template changes are not possible at runtime when doing AoT.

Expected behavior

It would be great if we could seamlessly bind Angular Elements to the DOM at runtime.

Minimal reproduction of the problem with instructions

Assume a case where you are binding a piece of html to the DOM at runtime (innerHTML)

content = "<my-angular-element></<my-angular-element>"
<div [innerHTML]="content"></div>

The code above will not work by default since the Angular DOM sanitizer will strip out the unknown element tag.

The current workaround is to manually bypass the template sanitization by running bypassSecurityTrustHtml. However, this turns off sanitization for the entire html fragment. Ideally we should still be able to run sanitization over anything that is not whitelisted.

Does it seem reasonable for the sanitizer to whitelist Angular Elements that are part of the hosting application?

One challenge of course is that the current api does not keep track of the registered element tags at the application level, but maybe it could?

What is the motivation / use case for changing the behavior?

Main use case is better support for dynamic Angular applications, without opting out of the important performance gains from AoT.

Thought?

cc: @robwormald @mhevery @IgorMinar

Environment

Angular version: X.Y.Z


Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

[robwormald]

My personal belief is that Angular Elements should not be treated as “special”… so the question is probably broader, to Custom Elements in general. We should definitely have a look at this, but just to set expectations, its not likely to happen soon, as messing with the Sanitizer requires Google Security reviews and such 😃

Note on a.io we just forgo the sanitizer, as we expect our own content to be trusted: https://github.com/angular/angular/blob/master/aio/src/app/layout/doc-viewer/doc-viewer.component.ts#L137

For an extra modicum of security, rather than going straight to innerHTML from a string of HTML, throw it into an HTML Template first.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity. Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}