Trusted Types Readiness: Is Your Site Ready to Enforce?

Enforcing Trusted Types on an unready codebase breaks pages. Enforcing it after careful preparation prevents a whole class of cross-site scripting vulnerabilities. The difference between those outcomes is readiness: knowing which sinks your code uses, whether third-party scripts comply, and what your report-only logs actually say. A readiness check turns that knowledge into a decision, so enforcement becomes a planned step rather than a hopeful switch.

The Trusted Types Readiness Checker reviews a pasted readiness summary — such as a sink inventory, a list of policies, or a summary of report-only violations — and assesses how close a site is to safe enforcement, highlighting gaps such as uncovered sinks, over-permissive policies, or third-party violations. It works from information you paste in; it does not scan your code or connect to your site, and it needs no credentials. Never paste secrets, tokens or private keys into it. A readiness summary contains sink names, policy names and violation counts, none of which require secrets.

Readiness has four dimensions, and a site should be honest about each. Code readiness means the site's own sinks are inventoried and covered by policies with real sanitisation. Third-party readiness means the libraries and embeds on your pages work under enforcement or have a plan. Policy readiness means policies are named sensibly, creation functions are reviewed, and no policy trusts input unchanged. Operational readiness means someone owns the violation reports, the rollout has stages, and rollback is possible. A site strong on one dimension and weak on another is not ready; enforcement exposes the weakest dimension first, usually in production.

Inventory first, then report-only logs

The inventory is the foundation. Search the codebase for dangerous sinks: innerHTML, outerHTML, insertAdjacentHTML, document.write, and script source assignments, plus framework-specific equivalents that compile down to them. For each sink, record the file, the data that flows into it, and whether that data can be influenced by users, by URL parameters, or by stored content. Sinks fed only by fixed internal strings are low risk and easy to handle; sinks fed by user data are the priority. An inventory without data-flow notes is a list of names, not a readiness assessment, because the same sink can be harmless in one place and critical in another.

Next, run report-only mode and read the logs properly. Report-only mode deploys the policy header without enforcement, so violations are reported to an endpoint instead of breaking pages. Let it run across real traffic for at least one full release cycle, and longer if traffic is seasonal or includes rarely visited pages. Then analyse the logs by sink, by page, and by script origin: your own code's violations are fixable directly, while third-party violations need vendor coordination or isolation. A log dominated by one page or one library points at a single fix with a large payoff; a log spread evenly across the site points at a systemic pattern, such as a shared helper that builds HTML strings, which should be fixed once at the source rather than patched page by page.

Distinguish violation counts from violation causes. A thousand violations from one sink on one page are one bug, while ten violations from ten different sinks are ten bugs. Fix by cause, not by count, and re-measure after each fix to confirm the log actually shrinks. If the log does not shrink after a supposed fix, the fix missed the real sink, or the same pattern exists in another copy of the code. Readiness improves when the log trends towards zero for your own code, even if third-party entries remain as a separate, tracked list.

Worked example: a site that thought it was ready

Suppose a medium-sized site inventories its sinks and finds twenty, all covered by two policies with proper sanitisation. The team feels ready and plans enforcement for the following week. As a final check, they run report-only mode for two weeks first. The logs tell a different story: in addition to the twenty known sinks, a marketing tag loaded through a tag manager creates script elements with string sources, a chat widget inserts HTML for its greeting bubble, and a legacy date picker builds its calendar with innerHTML. None of these appeared in the codebase search, because none of them live in the codebase; they arrive at runtime from third parties.

The team changes the plan. The marketing tag is replaced with a version that uses safe methods, the chat widget vendor confirms a compliant update and the team schedules it, and the date picker is replaced with a maintained alternative. After those changes, a second report-only run shows violations only from a single analytics snippet the team decides to isolate on pages that do not handle user content. Enforcement then proceeds on the main site, with the isolated pages following once the snippet is replaced. The two-week delay prevented a rollout that would have broken the chat widget and the date picker for real visitors, and the team now has a third-party review step in its change process so the problem does not recur silently.

The lesson is that readiness checking is not bureaucracy; it is the mechanism that finds runtime reality, which a code search alone cannot see. Tag managers deserve particular attention here, because they are designed to add code without a code change, which means they can also add sinks without a code review. Restrict who can publish through a tag manager, and include its contents in every readiness review.

Scoring readiness honestly

A simple scoring approach keeps the assessment honest. Give each dimension a plain rating: ready, mostly ready, or not ready, with evidence for each rating. Code is ready when every inventoried sink is covered and report-only logs show no violations from your own code over a full cycle. Third-party is ready when every third party either complies, is isolated, or is replaced, with no unowned exceptions. Policy is ready when every creation function has been reviewed and none trusts input unchanged. Operations is ready when violation reports have an owner, a review rhythm, and a tested rollback. Enforcement is justified only when all four read ready or mostly ready with a dated plan for the remainder. Anything less is a reason to delay, not a reason to hope.

Also plan the enforcement itself in stages. Enforce on a low-risk section first, such as marketing pages without user content, monitor for a week, then extend to the rest of the site. Keep the previous policy configuration saved so enforcement can be reverted quickly if a genuine problem appears. Announce the change to support and development teams beforehand, so a Trusted Types error in testing is recognised immediately rather than investigated as a mystery. Staged enforcement with monitoring is slower than a single switch and far safer, and the safety is the point.

Re-check readiness after major changes: a new framework version, a new third party, a redesign, or a migration can all introduce sinks or change policy behaviour. Readiness is a property of a codebase at a moment in time, not a badge earned once. The CSP Generator builds the policy header that carries Trusted Types directives, and the CSP Checker reviews an existing content security policy for gaps. For building the policies themselves, see HTTP Security Headers Guide.

FAQs

How long should report-only mode run? At least one full release cycle and long enough to cover real traffic patterns, typically two to four weeks for most sites. Rarely visited pages may need longer, or targeted testing, to appear in the logs.

What if a third party cannot comply? Weigh the options honestly: replace it, isolate it on pages without sensitive content, or delay enforcement for the affected pages while pressing the vendor. Document the exception, its risk, and its review date; an undocumented exception is a forgotten vulnerability.

Does readiness guarantee no breakage? No. It reduces the risk substantially by finding known sinks and third parties, but new code can always introduce a new sink. Pair enforcement with ongoing violation monitoring, so new problems surface as reports rather than as user complaints.