Review Angular templates, components, and their data-flow for the documented injection classes Angular's own sanitizer architecture is built to catch, and that are only unsafe when application code deliberately or accidentally routes around it: DomSanitizer bypass calls (bypassSecurityTrustHtml, bypassSecurityTrustUrl, bypassSecurityTrustResourceUrl) fed by user-reachable input, unsanitized [innerHTML] bindings, and dynamically bound iframe security attributes such as [attr.sandbox] that Angular's own NG0910 check exists to reject. This skill exists so the review stays anchored to these documented, concrete sinks instead of drifting into a general \"Angular code review\" — it does not re-litigate change detection, signals architecture, or component design in every response.
Use this skill when the user asks to:
\nbypassSecurityTrustHtml, bypassSecurityTrustUrl, or bypassSecurityTrustResourceUrl call is safe,[innerHTML] binding is safe,<iframe> embed for a dynamically bound security attribute ([attr.sandbox], [sandbox], [attr.allow], [attr.credentialless]) or an NG0910 error,Do not use this skill for:
\nangular-architecture-signals-review instead,TransferState leakage, hydration mismatches) — use angular-ssr-hydration-review instead,resolve-library-id (matched result: /angular/angular) before citing any sanitizer-mechanism or NG0910 claim./angular/angular is Angular's own source-and-docs repository (high reputation, corroborated against packages/platform-browser/src/security/dom_sanitization_service.ts, packages/core/src/sanitization/html_sanitizer.ts, packages/core/src/render3/instructions/shared.ts, and adev/src/content/reference/errors/NG0910.md). Use query-docs against it to confirm low-level sanitizer mechanics directly from source: that bypassSecurityTrustHtml (and its URL/resource-URL siblings) mark a value trusted so sanitize() skips the HTML/URL sanitizer and returns the value unchanged, that property bindings like [innerHTML] accept a compiler-added sanitizer function that only risky properties receive, and that text interpolation instead calls renderer.setValue() on a text node — a path that never parses HTML and needs no sanitizer.[attr.sandbox]/[sandbox]/[attr.allow]/[attr.credentialless] binding, confirm Angular's own NG0910 check: these attributes are documented as required to be static (fixed at element-creation time) because they configure the iframe's security model before src/srcdoc load — a dynamic binding either throws NG0910 in dev or, if that check is suppressed, lets a runtime value weaken the sandbox.DomSanitizer (from @angular/platform-browser) is actually in use before assuming a bypass call exists — do not assume a project uses the bypass APIs without confirming the import and call site.official_docs URLs in this skill's metadata.json and label the claim documentation-based, unverified against current release.bypassSecurityTrustHtml/bypassSecurityTrustUrl/bypassSecurityTrustResourceUrl call or an unsanitized [innerHTML] binding to MEDIUM just because it has not been observed exploited yet — the risk is in the structure, not in whether someone has already hit it.bypassSecurityTrustHtml, bypassSecurityTrustUrl, or bypassSecurityTrustResourceUrl call whose input includes user-reachable data unless the trace shows the value was validated or sanitized on that exact path before the bypass call — the bypass APIs are intentional escape hatches from Angular's compiler-driven sanitization, not accidental gaps, so their mere presence is not evidence of prior review.[innerHTML] binding fed by user-reachable input unless a named sanitizer call (e.g., DomSanitizer.sanitize(SecurityContext.HTML, ...), or a project-specific equivalent) is visibly present on that exact data-flow path. A sanitizer import existing elsewhere in the codebase does not clear this bar — trace the specific path under review.[attr.sandbox], [sandbox], [attr.allow], or [attr.credentialless] binding on an <iframe> as a finding regardless of whether NG0910 is currently thrown in the reviewed environment — a suppressed or bypassed dev-mode check does not make the underlying dynamic-security-attribute pattern safe in production.[href]/[src] bindings fed through bypassSecurityTrustUrl/bypassSecurityTrustResourceUrl for scheme validation (an allowlist rejecting javascript: and other non-http(s) schemes) on the traced path before the bypass call — the bypass call itself performs no validation.Load these only when needed:
\nbypassSecurityTrustHtml/bypassSecurityTrustUrl/bypassSecurityTrustResourceUrl call or an [innerHTML] binding. Includes the OWASP XSS grounding reference; load that citation only when a finding is actually present.<iframe> element with a bound sandbox, allow, or credentialless attribute, or a reported NG0910 error.Return, at minimum:
\nDomSanitizer call site(s) in scope,xss, url-injection, or iframe-sandbox-escape), the concrete data-flow trace (origin-to-sink path naming every hop), and a fix sketch matching Angular's documented pattern,[innerHTML] finding, an explicit statement of whether validation or sanitization is present on the traced path — never approve on the assumption one exists elsewhere,repo evidence, documentation-based, or inference), with structural risk findings explicitly labeled as structural risk, not as confirmed-exploited,