Skip to main content

Security Architecture: CSP and Trusted Types

Why this chapter matters​

Frontend security failures are often architecture failures: unsafe rendering boundaries, weak script governance, and inconsistent runtime policies.

CSP and Trusted Types are not bolt-on headers; they are architecture constraints that shape how UI code, libraries, and third-party integrations are allowed to execute.

Core mental model​

Model the browser as a policy-enforced runtime:

  • CSP controls where code/resources may come from.
  • Trusted Types controls how dangerous DOM sinks are written to.

If both are enforced, many XSS classes become significantly harder to exploit.

Decision framework​

DecisionConservative optionFlexible optionChoose based on
Script policyNonce/hash-only scriptsallowlist domainsThird-party dependency profile
Rollout modeReport-Only firstEnforce directlyApp complexity + blast radius
Trusted TypesStrict default policyCompatibility policyLegacy code volume

Implementation blueprint​

1) Baseline CSP policy rollout​

Start with Report-Only, collect violations, then enforce incrementally.

Recommended baseline concepts:

  • default-src 'self'
  • nonce/hash-based script-src preferred over broad allowlists
  • restrict connect-src to required API domains
  • lock frame-ancestors to prevent clickjacking

2) Trusted Types adoption​

  • Enable Trusted Types in report mode.
  • Inventory dangerous sinks (innerHTML, insertAdjacentHTML, script URL injections).
  • Replace ad-hoc HTML injection with audited sanitizer + policy wrappers.
  • Move to enforced Trusted Types after remediation.

3) Third-party script governance​

For each third-party script define:

  • business owner
  • technical owner
  • risk classification
  • performance and security budget
  • rollback switch

Anti-patterns and failure modes​

  • Anti-pattern: giant CSP domain allowlist.

    • Failure mode: effective security is close to unrestricted script execution.
    • Fix: move to nonce/hash model and shrink exceptions.

  • Anti-pattern: enabling Trusted Types without sink inventory.

    • Failure mode: widespread runtime breakages.
    • Fix: staged migration and compatibility policy window.

  • Anti-pattern: no telemetry on policy violations.

    • Failure mode: silent policy drift.
    • Fix: route violation reports into SIEM/alerting.

Verification checklist​

  • CSP exists in Report-Only and Enforce modes with documented rollout plan.
  • Nonce/hash usage is automated by framework/build pipeline.
  • Trusted Types policy and sanitizer ownership are defined.
  • Dangerous sink usage is linted and monitored.
  • Third-party scripts have owners and kill-switch strategy.

Architecture drill​

Scenario​

A legacy authenticated app has many inline scripts, CMS-rendered HTML, analytics tags, and several innerHTML usage sites. Security wants CSP and Trusted Types enforced within one quarter.

Decision prompt​

Design a staged adoption plan that reduces XSS risk without breaking critical workflows.

Expected architect-level answer​

Start with report-only telemetry, inventory dangerous sinks, define sanitizer/Trusted Types policy ownership, replace broad script allowlists with nonce/hash strategy where feasible, classify third-party scripts, and enforce by route/risk class.

Common weak answers​

  • turning on strict enforcement immediately across the whole app
  • using a giant allowlist and calling CSP complete
  • enabling Trusted Types without sink inventory or migration owners

Artifact to produce​

Create a 30/60/90-day CSP and Trusted Types rollout ADR plus a third-party script register.

Metrics and scorecards​

Track monthly:

  • CSP violation rate by directive
  • Trusted Types violation count by route
  • Number of high-risk third-party scripts
  • Mean time to revoke vulnerable script integration
  • Security regression escape rate post-release

At-scale adaptation​

  • Add security architecture checks to PR templates and ADR approvals.
  • Create a shared secure rendering library for all teams.
  • Require threat-model review for any new HTML injection pathway.
  • Standardize incident playbooks for XSS-class findings.

Exercise​

Create an adoption plan for an existing app:

  1. Draft Report-Only CSP and violation collection plan.
  2. Identify top 10 dangerous sinks and remediation owners.
  3. Propose 30/60/90-day path to CSP + Trusted Types enforcement.

Source lens​

Use MDN CSP and Trusted Types documentation for browser behavior, OWASP guidance for XSS risk framing, and your organization's security policy for enforcement thresholds and reporting requirements.