Re: [whatwg/dom] [Declarative Shadow DOM] How should we build the "opt-in" for fragment parsing of declarative Shadow DOM? (#912)

@annevk I like the safe-by-default aspect of it and how it enables incorporating sanitizer later. However, it still adds a new DOM XSS sink to the platform, it's just one that is more complicated to call, as it also requires control over the option bag argument. Granted, one of the keys in that bag suggests there's something security-related going on, but existing tools don't know that. 

In some aspects it's even worse than `innerHTML` in that determining if the code causes XSS depends now on two separate values, both of them potentially dynamic. That makes automated analysis and manual review harder. For example:

```javascript
el.setInnerHTML(componentHTML, config.componentRenderer.params)
```

To find out whether this is an XSS, we have to inspect the data flow for two different arguments, and changing *either* in the future has security consequences.

If DOM should add a new XSS sink (and this one looks to be potentially popular as a "better innerHTML"), I think the bar should be higher than the default (non-functional in v1) being safe, and the security controlled by just the object key names.

@mfreed7 how crucial is it to have the `setInnerHTML` case in v1? Do you expect the declarative shadow DOM to be commonly using this function? Can the other, already existing and unsafe sinks be used by the authors instead of `setInnerHTML` or does `setInnerHTML` have a unique behavior that you want to preserve?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/912#issuecomment-731067930