Google fights DOM XSS with Trusted Types

by Surabhi Sinha, Product Manager on July 15, 2021

DOM-based cross-site scripting (DOM XSS) attacks are one of the most prevalent and dangerous web security vulnerabilities. In DOM XSS attacks, malicious code is executed inside the browser, making them particularly difficult to detect and block. Google, in continuation with its roll out of strict CSP across mission critical applications, has deployed the HTTP Content-Security-Policy (CSP) trusted-types directive across 130 services built on Google’s main web application framework including Google Photos and Google Contacts. According to a report published by Google recently, the deployment has led to zero incidence of DOM XSS in these applications.

What is DOM XSS

The ability to control and/or modify the document object model (DOM) is attractive to attackers because it provides complete control over the website experience and any data entered or rendered there. There are two distinct groups of cross-site scripting:

Those caused by the server-side code that insecurely creates the HTML code rendering the website
Others are caused on the client side, where the JavaScript code calls dangerous functions with user-defined content

Given the complex and dynamic nature of modern web applications, maintaining an XSS-free application could prove challenging. While solutions for preventing server-side XSS are well known, DOM-based Cross-Site Scripting (DOM XSS) is a growing problem.

Sponsorships Available

How prevalent are DOM XSS vulnerabilities

The application code typically contains a number of dangerous JavaScript constructs or sink functions that can prove risky and expose the application to cross site scripting attacks. Some of these functions include:

innerHTML, outerHTML, insertAdjacentHTML, document.write, document.writeln are functions that can be used to generate HTML from a string
Eval, setTimeout, setInterval, new Function() can be easily manipulated as they are used for runtime javascript code compilation. For example, running eval() with a malicious string may end up running malicious code on the user’s machine with the permissions of the webpage.

A 2020 study conducted by Tala on Alexa 1K websites identified an increasing number of DOM XSS risks. The graph below shows the incidence of potential injection points, such as document.write(), eval(), and innerHTML() among the study sample. A significant majority of websites are using dangerous JavaScript functions that could serve as injection points to initiate a DOM XSS attack; the innerHTML function was found operating on 97% of websites.

Trusted Types and Google’s implementation

The HTTP Content-Security-Policy (CSP) trusted-types directive allows the locking down of known DOM XSS sinks to a predefined set of functions that cannot be called with strings. This allows developers to define restrictions to values that can be written to the DOM, protecting the DOM XSS sinks by design. This works by declaring a white-list of trusted type policy names created with TrustedTypes.createPolicy from Trusted Types API. Current Trusted Types include HTML, URL, ScriptURL, and Script.

Since 2019, Google has deployed Trusted Types in over 130 services and observed zero incidence of DOM XSS in those applications. The use of Trusted Types has also led to many practical benefits according to Google’s Krzysztof Kotowicz:

More than 60% of DOM XSS that could not be captured through static analysis can be discovered through Trusted Types
Auditing code is much easier with ‘Trusted Types’ as it just involves checking all code that generated Trusted Types rather than verifying every DOM XSS injection point
Trusted Types can help eliminate the practice of using risky JS constructs and encourage code that is secure by design as the browser helps validate that dangerous JS constructs are not used

Defense in depth for client side security

It’s fair to say that Content Security Policy directives have evolved into an essential component of any comprehensive, client-side security strategy. Combined with other industry-endorsed standards such as SRI and others, it gives a strength-in-depth response to web security that’s in-step with the web we have today, and the web we’ll have tomorrow.