Hi all,
*Summary*: We would like to expose a sanitizer API that accepts "bad" HTML (string, DocFragment) and returns a sanitized DocFragment, using a pre-defined list of allowed elements / attributes. The implementation is using code that we have had in mozilla-central for a long while: The existing nsTreeSanitizer is widely used (e.g., when pasting HTML into a document or in Reader Mode). We believe that exposing this will be useful for applications that want to protect themselves from XSS while allowing a subset of HTML. *Bug*: <https://bugzilla.mozilla.org/show_bug.cgi?id=1650370> Standard: Still just a WICG draft at <https://github.com/WICG/sanitizer-api> *Platform coverage*: All supported platforms. *Preference*: Requires dom.security.sanitizer.enabled to be true *DevTools bug*: <https://bugzilla.mozilla.org/show_bug.cgi?id=1652671> *Other browsers*: Blink is prototyping, see <https://groups.google.com/a/chromium.org/g/blink-dev/c/MJxVZs1H5SY/m/6q0QxEFtBAAJ> *web-platform-tests*: WPT will be the primary test suite. However, we'll keep a small mochitest in central for easier testing while we experiment with API details and the final WebIDL. This will allow us to test things independently, before we reach consensus. We expect the mochitests to be fully replaced before this is exposed by default. *Secure contexts*: Yes, required. *Is this feature enabled by default in sandboxed iframes?* This API is exposed via JavaScript, which sandboxed iframes do not allow. Sandboxed iframes with "allow-script" will be able to make use of this API. *Link to standards-positions discussion*: worth prototyping (<https://github.com/mozilla/standards-positions/pull/395>) *How stable is the spec*: The API is getting stabler, but there are lots of open questions when it comes to what ought to be allowed by default. Concerns with forward/backward compatibility are not yet completely resolved. Even with a list of safe HTML elements, script gadget attacks need to be taken into account (https://raw.githubusercontent.com/google/security-research-pocs/master/script-gadgets/ccs_gadgets.pdf). *Security & Privacy Concerns*: This API does not expose information about the user, their system or session. Some security questions regarding compatibility have not been fully answered though. See note above. *Web designer / developer use-cases*: Implementations as JavaScript libraries exist, e.g., DOMPurify. However these implementations face significant challenges: 1) Walking an attacker-controlled DOM tree is extremely challenging. The page at <https://portswigger.net/web-security/dom-based/dom-clobbering> gives an example of DOM clobbering attacks, in which elements with id="attribute" can shadow the parent element's "attribute" property. 2) Parsing ambiguities between security library and browser can lad to security bugs. We're hoping that an implementation which matches the browser's parsing behavior will eradicate this issue. In essence: We know thatframeworks and single-page applications already make use of this feature, but we hope to provide a better level of security that can overcome the problems that a JS implementation has to face. *Example*: ``` mySanitizer = new Sanitizer(/* some options *); mySanitizer.sanitize("<p>hello!<script>alert('oops');</script></p>); // returns DocumentFragment [ <p>hello!</p> ] ``` Kind regards, Freddy _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform