Angular 应用程序默认具备安全性，大多数安全漏洞源于开发人员绕过这些内置保护机制。Angular 拥有一个自动处理值并在将其渲染到 DOM 之前进行处理的清理管道（sanitization pipeline）。该管道区分了转义（escaping）、清理（sanitizing）和信任（trusting），其中信任会显式绕过自动检查。存在四个不同的安全上下文（SecurityContexts）：HTML、STYLE、URL 和 RESOURCE_URL，每个上下文具有不同的风险特征和处理方式。DomSanitizer 用于对输入进行清理，或使用 Safe* 类型显式信任输入。反模式涉及在不信任的输入上绕过安全，这会在安全审查中立即引发警示。绕过安全有时具有合理性，但需要仔细考量并清晰理解相关风险。在不绕过清理机制的前提下安全地渲染 Markdown 被提出作为一种更优的替代方案。SafeResourceUrl 对于受信任的 iframe 嵌入至关重要。SafeUrl 通常不需要用于标准锚标签。Angular 应用程序中的 CSRF 防护是前端和后端共同承担的责任。HTTP Interceptors 可作为安全执行层。内容安全策略（Content Security Policy）和可信类型（Trusted Types）可进一步增强前端安全性。文章还涉及了服务端渲染（SSR）和水合（hydration）的考量。最终，安全性是前端和后端共同分担的责任。文章总结了常见错误，提供了生产环境安全审查清单，并在结语中强调应遵循 Angular 的安全模型开展工作。