Why Trusted Types Audit Exists

The Trusted Types Audit is the audit you reach for when you already suspect a problem in this dimension and need a fast, copy-paste-able fix list. It reuses the same chrome as every other jwatte.com tool — deep-links from the mega analyzers, AI-prompt export, CSV/PDF/HTML download — but the checks it runs are narrow and specific.

Checks Trusted Types CSP directives and scans for dangerous DOM sinks (innerHTML, outerHTML, insertAdjacentHTML, eval). Trusted Types block DOM XSS.

Why this dimension matters

Modern browsers fail closed on missing or misconfigured security headers — a single wrong header (CSP with unsafe-inline, ACAO wildcard with Allow-Credentials: true, SRI hash mismatch) turns a production site into an XSS or data-exfiltration risk. Audit-side these are silent; users notice only after a breach or a PCI / SOC-2 review asks.

Common failure patterns

• Permissive CORS combined with credentials — Access-Control-Allow-Origin: * plus Access-Control-Allow-Credentials: true is ignored by browsers but signals sloppy review. The real failure is ACAO echo-back (reflecting any Origin header) paired with credentials; that exposes authenticated endpoints to cross-site scripts.
• CSP unsafe-inline / unsafe-eval — a CSP that allows inline or eval defeats most of its own purpose. Modern apps should emit nonces or hashes and remove inline handlers; the audit flags the pattern and points to the Trusted Types + Inline Event Handler tools as the next step.
• Security headers on HTML but not on APIs — the HTML response gets HSTS, CSP, and X-Frame-Options; the JSON API response doesn't. An attacker only needs one unhardened origin.

How to fix it at the source

Start from a deny-by-default CSP and relax per directive. For CORS, prefer an explicit allowlist over *. Apply headers at the CDN / edge layer (Netlify _headers, Vercel vercel.json, Cloudflare Transform Rules, nginx add_header) rather than in application code — the edge layer catches every response consistently.

When to run the audit

• After a major site change — redesign, CMS migration, DNS change, hosting platform swap.
• Quarterly as part of routine technical hygiene; the checks are cheap to run repeatedly.
• Before an investor / client review, a PCI scan, a SOC 2 audit, or an accessibility-compliance review.
• When a downstream metric drops (rankings, conversion, AI citations) and you need to rule out this dimension as the cause.

Reading the output

Every finding is severity-classified. The playbook is the same across tools:

• Critical / red: same-week fixes. These block the primary signal and cascade into downstream dimensions.
• Warning / amber: same-month fixes. Drag the score, usually don't block.
• Info / blue: context-only. Often what a PR reviewer would flag but that doesn't block merge.
• Pass / green: confirmation — keep the control in place.

Every audit also emits an "AI fix prompt" — paste into ChatGPT / Claude / Gemini for exact copy-paste code patches tied to your stack.

Related tools

• Mega Security Analyzer — Seven security layers in one scan: TLS, PQC hybrid-KEX, HTTP security headers, DNS email-auth (SPF/DKIM/DMARC/CAA), CSP strictness, MITRE ATT&CK tactic mapping, CWE / OWASP / SANS pattern scan.
• CSP Strictness Audit — Deep CSP audit: nonce/hash coverage, strict-dynamic, unsafe-inline, report-to, Trusted Types, wildcard quality..
• CORS Headers Audit — Deep CORS audit: ACAO * + credentials, Vary: Origin, Allow-Methods, Expose-Headers, Max-Age, Timing-Allow-Origin..
• Subresource Integrity (SRI) Audit — Checks SRI integrity hash coverage on every cross-origin