Re: [whatwg/dom] Declarative Shadow DOM (#831)

> Oh, I see. That would be indeed problematic. We probably need to make DOMParser and other DOM API to parse HTML not handle declarative Shadow DOM by default.
> 
> However, the sanitizer scenario that I had concerned been concerned was mainly ones that parse HTML in the server side and strips away any scripting content. Such a sanitizer would see the markup for `<template shadowroot>` as well as its content yet it won't know that this template element's content won't be inert. For that case, using `<shadowroot>` instead is an effective mitigation strategy because such a server-side parser would treat it as like any other element of known name.

In both scenarios (client side and server side), do you know of any sanitizer whose default behavior is to allow `<template>` elements through as-is, with no filtering of child nodes? I looked at [these three](https://www.npmtrends.com/dompurify-vs-sanitize-html-vs-xss), which seem to be the most popular, and none even allow `<template>` elements at all by default. In other words, all three, by default, are safe against this issue. Which sanitizer, exactly, are you thinking about that sees `<template>` elements and allows through all child nodes, unfiltered? I haven't found one that does that, but perhaps I missed it. I would like to reach out to the authors to get this fixed, as this issue will also affect template instantiation and declarative custom elements, and any other potential uses of the `<template>` element, as @justinfagnani [points out](https://github.com/whatwg/dom/issues/831#issuecomment-714614006).

I completely understand the concern about XSS issues. But blocking an entire feature (or otherwise making it much less usable, e.g. by adding HTTP header [footguns](https://github.com/whatwg/dom/issues/831#issuecomment-716078525), or disallowing `innerHTML` usage) based on this concern doesn't seem to make sense to me. Browsers add new XSS vulnerabilities all the time - they're called "bugs". And security is an ongoing process of continuous work. That's why most browsers themselves are released very frequently, to be able to keep up with security issues. This is just another emerging security issue, which does need to be taken into account by sanitizer libraries. Fortunately, this one (as opposed to the bugs) is known ahead of time. I just don't believe we need to block all new features based on the oldest and/or most-misconfigured sanitizers in use across the web.

-- 
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/831#issuecomment-716681584