Latest specification is a work in progress
Sanitizing dynamic markup and making sure it does not contain harmful code is one of the most serious challenges of web security.
Native sanitization support
Currently, web developers rely on third-party libraries such as DOMPurify to sanitize HTML content and prevent XSS attacks.
The Sanitzer API, which was first proposed earlier this year in a draft specification, will give browsers native support to remove harmful code from markup that is dynamically added to web pages.
The API is being jointly developed by Google, Mozilla, and Cure53, the maintainer of the DOMPurify library.
“The new Sanitizer API proposal is the first step towards a standardized API for a common task that many frontend libraries (e.g, React, Vue) or sanitizers (e.g, DOMPurify, sanitize-html) already perform when developers need to explicitly render unsafe HTML where they want to,” Lorenzo Stella, application security engineer at Doyensec, told The Daily Swig.
Stella says that delegating sanitization to the browser makes it more accessible, secure, and hopefully faster.
“The browser already has a good and safe parser, and knows best how it will treat each active element in the DOM. An external parser written in JS has overhead and is likely to be worse and outdated compared to the browser,” he said.
Work in progress
The Sanitizer API is still in test mode and available in Firefox Nightly and Chrome 94+ through special flag settings.
“We’re calling for developers with various different perspectives to test and experiment with the preview in order to ensure that the Sanitizer API clearly solves developers’ needs and expectations at initial rollout, which includes allowing the easy adoption of existing code,” Frederik Braun, security engineer at Mozilla, told The Daily Swig.
The latest update to the draft, published last week, has ironed out some of the kinks in the original specification.
The new version of the sanitizer takes the DOM context into account when sanitizing markup snippets, which patches some of the XSS security holes that previous sanitizers had. It also makes it easier to update old code to use the native sanitization features.
“XSS is still one of the most dangerous security issues, and consistently ranked highest in the list of the Most Dangerous Software Weaknesses by MITRE,” Braun said.
“The Sanitizer API is going to help developers mitigate the XSS problem by exposing a primitive that accepts potentially harmful HTML and returns guaranteed safe HTML.”
In comments to The Daily Swig, browser security researcher Jun Kokatsu called Sanitizer API “an important step towards securing the web”.
The reliance on third-party sanitization opens the way for mutation XSS, a type of attack that takes advantage of the differences in how various browsers parse HTML data, Kokatsu said.
“With Sanitizer API, browsers are now responsible for sanitization as well, and it’s more likely that changes to the HTML parser will be more carefully done,” Kokatsu said.
“For example, adding a new HTML tag has to go to the Sanitizer API’s owner to discuss if it should be blocked by the sanitizer or not.”
Complementing other security tools
Doyensec’s Stella warned that the Sanizer API should not be considered as a “catch-all mechanism for all web applications”.
“There can be sanitization requirements that are not easily met by a general-purpose API like this. However, the library should play well with other enforcement mechanisms,” he said.
Kokatsu said that the Sanitizer API can be a good complement for other security mechanisms being built into browsers, including Trusted Types, a new specification that makes it difficult to stage DOM-based XSS attacks on websites.
“While Trusted Types aims to prevent DOM-based XSS, HTML sanitization had to be provided by the developers. However, with Sanitizer API, developers can simply use the built-in Sanitizer API,” he added.