---
title: "Angular frontend security and trust boundaries"
chapter: "18"
---

# Angular frontend security and trust boundaries

The browser is an untrusted client. Angular reduces some rendering risk but
cannot enforce backend authorization or protect secrets delivered to users.

## XSS

Angular escapes interpolated values and sanitizes supported contexts. Avoid
`innerHTML`; never use `bypassSecurityTrust*` to silence warnings without a
reviewed provenance and sanitization contract.

URLs, styles, HTML, and resource URLs have different trust rules. Content
Security Policy and Trusted Types add defense in depth.

## Authentication and authorization

Client route guards and hidden buttons improve experience only. APIs enforce
permissions and resource ownership. Avoid storing long-lived bearer tokens in
JavaScript-readable storage when safer architecture is available.

## CSRF and CORS

Cookie-authenticated state changes need CSRF defenses. CORS is a browser
read-policy, not authentication. Configure exact trusted origins, credentials,
methods, and headers.

## Supply chain

Pin lockfiles, review install scripts and maintainers, scan dependencies,
generate an SBOM, use trusted registries, sign artifacts, and patch supported
Angular/Node/runtime versions. Tailwind and Flowbite are build/runtime
dependencies with supply-chain impact.

## Sensitive data

Never place secrets in environment files bundled into JavaScript. Treat logs,
analytics, source maps, error reports, browser storage, SSR HTML, and Transfer
State as possible disclosure paths.

## Deployment headers

Set CSP, frame-ancestors, nosniff, referrer policy, permissions policy, HSTS,
safe caching, and immutable hashed assets. Do not cache personalized SSR HTML
publicly.

## Feynman check

If the browser can use a secret, the user can inspect it. Explain why frontend
code can guide authorization but never be its final authority.