Google, Mozilla close to finalizing Sanitizer API for Chrome and Firefox browsers
For a long time, app developers have been looking for ways to protect their web applications from XSS attacks better. Luckily, this can end now because leading browsers, Google and Mozilla, are just about done with the Sanitizer API to solve this very problem promising the feature in the upcoming versions of Firefox and Chrome.
HTML sanitization is a process developers use to parse an HTML document and eliminate any harmful code. At the end of the procedure, a new document is created that only contains “secure” code and the desired tags.
Sanitization makes sure that any code submitted by a user or even generated by a browser is safe to run. This is why an HTML sanitizing program is super useful in defending against XSS attacks.
So far, the sanitization process depends on whitelist and blacklist strategies, including further methods that rely on rules that define which operations can be performed on specific subject tags.
In the event of rending content submitted by external users, or working on third-party templates web applications processing often involves dynamic HTML within the browser. This opens up the chance for the introduction of security trapdoors and faults that malicious actors can manipulate to stage XSS attacks and exploit user data.
To prevent these attacks, most developers are compelled to use open-source JavaScript application libraries, including DOMPurify, that take the HTML input as strings and sanitize it by deleting any code that could be a security vulnerability.
Even though this works, it still requires the integration of external libraries and sending data over to them, which itself is a security concern. Sanitizer API aims to delegate this process to the browser itself. It can be instantiated and used natively without importing additional libraries, making the process safer, quicker, and more efficient.
Native Sanitization Support
In a draft specification earlier this year, the Sanitizer API was proposed by Google, Mozilla, and Cure53 to finally attempt to solve this problem.
“The brand-new Sanitizer API proposal is step one in direction of a standardized API for a typical process that many frontend libraries or sanitizers already carry out when builders must explicitly render unsafe HTML the place they need to,” application security engineer, Lorenzo Stella at Doyensec, told The Each day Swig.
“The browser already has a secure parser and is aware of the greatest way it will deal with every lively ingredient within the DOM. An exterior parser written in JS has overhead and is more likely to be worse and outdated in comparison with the browser,” he further commented.
Work in progress
The API is currently in test mode and is only available for use on Firefox Nightly and Chrome 94+, and that too with special flag settings.
In the words of Fredrick Braun, a security engineer at Mozilla, “We’re calling for developers with various perspectives to test and experiment with the preview to ensure that the Sanitizer API solves developers’ needs and expectations at initial rollout, which includes allowing the easy adoption of existing code,”
The original specification was reported to have specific issues and bugs, which were then identified ironed out in the latest release. The new version takes the DOM approach and patches the previously detected XSS security loopholes, making it much more efficient to update existing code to use the new sanitization features within the browsers.
Braun also commented that “XSS is still one of the most dangerous security issues, and is consistently ranked highest in the list of the Most Dangerous Software Weaknesses by MITRE.”
The traditional approach of relying upon third-party apps makes code more prone to mutation XSS, an advanced type of XSS attack that manipulates the code according to the differences between different browser-specific methods of parsing HTML code.
Delegating the sanitization step to the browser natively makes sure that any changes to the HTML are more carefully made, with a lower risk of being infiltrated by external parties.
Complementing other security tools
Even though the API will make sanitizing the code a whole lot safer and easier, according to Stella, it still should not be taken 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 commented.
On the contrary, the API can be used as an add-on to other security systems and mechanisms, especially those built into browsers, including Trusted Types, a brand-new specification designed to keep DOM-based XSS attacks at bay.
