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.