Ensure support for Trusted Types

[36degrees]

What

Trusted Types are a relatively new browser feature designed to the DOM XSS attack surface of a website or web app. They are enforced by setting new Content Security Policy (CSP) directives which then lock down 'risky sink functions':

• Script manipulation:
  <script src> and setting text content of <script> elements.

• Generating HTML from a string:
  innerHTML, outerHTML,insertAdjacentHTML, <iframe> srcdoc, document.write, document.writeln, and DOMParser.parseFromString

• Executing plugin content:
  <embed src>, <object data> and <object codebase>

• Runtime JavaScript code compilation:
  eval, setTimeout, setInterval, new Function()

At time of writing, we use innerHTML in a few places. We also use setTimeout and setInterval, but I believe they are only affected if passing a string instead of a function.

The scope of this work would be to ensure that if a consumer of GOV.UK Frontend enforces trusted types in their service, GOV.UK Frontend does not trigger any violations.

We would likely need to:

• add tooling to help us identify potential violations
• rewrite offending code or introduce appropriate trusted type policies

Optionally, we may choose to introduce guidance on using GOV.UK Frontend with Trusted Types, especially if we have to introduce additional policies or rely on polyfills etc.

Why

Updating GOV.UK Frontend to support Trusted Types makes it easier for service teams to adopt Trusted Types, improving the security of government services.

However, there is a workaround for service teams enabling Trusted Types – they can create a default policy. Note that the example default policy provided in the linked guidance introduces a dependency on DOMPurify, a JavaScript library which is approx 21kB minified.

Trusted Types seem to be gaining traction across the web. Chrome's telemetry data suggests that more than 10% of page loads have trusted types enabled.

Trusted Types are currently only supported in Chromium browsers, however Mozilla have shown positive signals and Webkit at least seem to be considering it.

Who needs to work on this

Developers, tech writer?

Who needs to review this

Developers

Done when

• We have tooling to help us identify any potential Trusted Type violations, allowing us to ship changes with confidence
• We have rewritten any offending code or introduced appropriate trusted type policies
• We have published any guidance that might be required to use our code effectively in an environment where Trusted Types are enabled

[36degrees]

To my knowledge we have had one instance of this coming up on support, with the Accordion component causing a "This document requires 'TrustedHTML' assignment" error. The user in question followed the guidance on using a default policy and as far as I know this solved the immediate problem.

I ran a highly unscientific x-govuk Slack poll in February asking about people's awareness of Trusted Types. Of the 8 people that responded, 7 had never heard of it and only 1 is using it in production.

So my general sense is that this hasn't yet found much of a foothold in the GOV.UK estate. This may be partially due to the relatively low amount of user-generated content being displayed to other users, which means the XSS attack surface is relatively low to start with? 🤷🏻‍♂️

[36degrees]

If we do pick this up, my suggestion would be to try and re-write code to avoid using the sink functions before we start introducing policies etc, unless doing so adds significant amounts of code or complexity.

My reasoning for this is:

1. It aligns with the guidance in this comment:

   There are misconceptions of how Trusted Types is used: The goal is not to use "trusted" strings (and the factories that create them) everywhere in your application; the goal is to refactor the applications to use non-XSSy DOM sinks as much as possible. The creation of trusted type factories and trusted strings instances is largely a transition measure to help get an application from its legacy state to a safe-by-default state, where one can then simply use require-trusted-types-for "script" to lock it down.

2. Avoiding the complexity of policies reduces the level of technical expertise required to contribute, or read and understand the code.

[36degrees]

Some useful resources:

• https://github.com/w3c/trusted-types, including an explainer
• https://w3c.github.io/trusted-types/dist/spec/
• Trusted Types mozilla/standards-positions#20
• Trusted Types WebKit/standards-positions#186
• https://github.com/google/tsec – Extended TypeScript compiler checking Trusted Types compatibility