v157 · sanitizer api · practical product use case
Untrusted comment feed
A comment section wants links — so href goes on your attribute allowlist. That is precisely the moment a javascript: href becomes an XSS vector, and precisely what this option governs. Below, hostile comments are rendered through the real Sanitizer API with links allowed, in your choice of the safe path or the newly expressible unsafe-but-no-script-URLs path, and every surviving link is audited.
Probing…
Render the feed
Not rendered yet.
why the unsafe path at all?
The safe path (setHTML) strips comments, data-* attributes and anything XSS-unsafe, always — including javascript: URLs, with no opt-out (removeUnsafe() forces the option off). But real pipelines sometimes need the permissive parse: a CMS that round-trips editorial comments, a widget that relies on data-* hooks, or markup that embeds inert <template> machinery. Before 157 that meant setHTMLUnsafe — and silently keeping javascript: hrefs. Now { sanitizer: { javascriptURLs: false } } gives the permissive parse without the script-URL hole. If your page also enforces Trusted Types (require-trusted-types-for 'script'), note setHTML() needs no policy while unsafe sinks may — see the guidance link below.