An Angular app that enforces Trusted Types always needs the angular policy. Add angular#bundler for lazy loaded chunks, angular#unsafe-bypass if you call any DomSanitizer bypass method, angular#unsafe-jit for JIT compilation, and angular#unsafe-upgrade for AngularJS hybrid apps. The unsafe names double as a flag for reviewers.
What Trusted Types are
Trusted Types is a web platform feature that helps prevent cross-site scripting by enforcing safer coding practices at the DOM sinks. Instead of letting any string flow into a dangerous sink, the browser requires a typed, policy approved value. The Angular guide recommends it, says it can simplify auditing application code, and notes that these DOM level protections cannot be bypassed using lower level APIs.
If a browser does not support Trusted Types, the app still works and Angular's DomSanitizer continues to protect it. Check current browser support before relying on it as your only layer.
The policies
| Policy | When you need it |
|---|---|
| angular | Always, when enforcing. Used by security reviewed code internal to Angular. Inline template values and content sanitized by Angular are treated as safe by it |
| angular#bundler | When the Angular CLI bundler creates lazy chunk files, so lazy loaded modules work |
| angular#unsafe-bypass | If your app uses any DomSanitizer bypass method, such as bypassSecurityTrustHtml |
| angular#unsafe-jit | If you interact directly with the JIT compiler or run in JIT mode |
| angular#unsafe-upgrade | If you use the upgrade package, that is an AngularJS hybrid |
The names that contain "unsafe" are a useful signal. Seeing one in your headers tells a reviewer that the app has a bypass, a runtime compiler or a legacy hybrid.
Example headers
The guide shows these header shapes.
Content-Security-Policy: trusted-types angular; require-trusted-types-for 'script';
Content-Security-Policy: trusted-types angular angular#unsafe-bypass; require-trusted-types-for 'script';
Content-Security-Policy: trusted-types angular angular#bundler; require-trusted-types-for 'script';
An app with lazy loading and bypass calls would list both extra policies. Configure the headers in three places: your production serving infrastructure, the Angular CLI dev server through the headers property in angular.json, and Karma through the customHeaders property in karma.config.js, so tests run under the same rules.
A rollout path
- Start by listing every bypassSecurityTrust call. Each one forces an unsafe policy name. Remove the ones you can.
- Turn on enforcement in a test environment first and watch the browser console for violations.
- Add only the policy names you truly need. Do not add extra ones to quiet an error before you understand it.
- Ship, and keep violation reporting on, so new bypasses are noticed.
- Treat any new unsafe policy name in a pull request as a review trigger.
Related reading: when bypassSecurityTrust is safe to use and Trusted Types explained for DOM XSS.
Reading violations in the console
When enforcement is on and code writes a plain string to a dangerous sink, the browser blocks it and reports a violation. In a rollout, group the violations by source file. A violation inside your own component usually means a direct DOM write that should become a template binding. A violation from a library points to a dependency that needs an upgrade, a replacement, or an explicit reviewed exception. Do not widen the policy list until you know which case you are in.
Quick check
Do I need the unsafe policies if I never bypass the sanitizer?
Only if you use JIT compilation or an AngularJS hybrid. Otherwise the angular policy, plus the bundler policy for lazy chunks, is the starting point.
Does Trusted Types replace the sanitizer?
No. They are layers. If a browser lacks Trusted Types, Angular's DomSanitizer still guards the app.
Safeguard's free scan at gold.safeguard.sh/scan checks the packages behind an Angular build.
Sources
Last reviewed: 19 October 2026.
