# Dynamic Iframe Security Attributes

Use this reference only when the review scope includes an `<iframe>` element with a bound `sandbox`, `allow`, `credentialless`, `csp`, `referrerPolicy`, or `fetchPriority` attribute, or a reported NG0910 error.

## What people get wrong

The naive assumption is:

> "Angular throws NG0910 if I bind these attributes dynamically, so if my app runs without that error, my iframe binding must be fine."

Wrong in two ways. First, the check can be suppressed or not exercised in the exact code path under review (a conditional branch not hit during development, or an older Angular version without the check). Second, even when the error is correctly thrown and "fixed" by refactoring around it, the underlying intent — a *dynamic*, potentially user-influenced sandbox/allow value — is still the actual security concern, independent of whether the specific Angular version enforces it at compile/runtime.

## Officially grounded rules

Angular's own documentation (`documentation-based`, `adev/src/content/reference/errors/NG0910.md`, confirmed via Context7 `/angular/angular`) states directly:

- **Angular throws NG0910 when it detects a binding on specific security-related `<iframe>` attributes**: `sandbox`, `allow`, `allowFullscreen`, `referrerPolicy`, `csp`, `fetchPriority`, or `credentialless`. These attributes configure the iframe's security model and must be applied before the `src`/`srcdoc` attributes load content, so Angular requires them to be static — their values fixed at element-creation time and never bound as a property (`[sandbox]="..."`) or attribute (`[attr.sandbox]="..."`) binding, including via a directive's host bindings.
- **The recommended fix is a static attribute**, e.g. `sandbox="allow-scripts"`, or Angular's `@if`/`@switch` control-flow blocks to conditionally render entire `<iframe>` elements with different static attribute values, rather than binding the attribute's value dynamically on one persistent element.

## Non-negotiable design rules

### 1. Flag the pattern regardless of whether NG0910 currently fires

A dynamically bound security-sensitive iframe attribute is the finding — not the NG0910 error message itself. If the error is suppressed (an older Angular version, a downgraded compiler check, or code that technically avoids triggering the exact check Angular implements) but the underlying dynamic-binding pattern is present, it is still a finding: the sandbox's actual value can still be influenced by whatever expression it is bound to.

### 2. Check reachability of the bound expression

A `[attr.sandbox]` bound to a hardcoded, non-configurable constant expression evaluated once at compile time is a lower-severity finding (still worth fixing for forward-compatibility with future Angular checks) than one bound to a value that traces back to user-reachable input (a query parameter, a per-tenant config value editable by end users, or similar) — the latter is a HIGH finding because an attacker-influenced value can directly weaken the iframe sandbox.

### 3. Use static attributes or conditional rendering, not dynamic binding

The correct fix is either a static attribute value or Angular's `@if`/`@switch` blocks rendering distinct `<iframe>` elements per case — not attempting to bind the attribute dynamically through a workaround (e.g., manual DOM manipulation via `ElementRef` to set the attribute outside Angular's binding system), which reintroduces the same risk outside Angular's own safety check.

## Minimal safe implementation pattern

```html
<!-- Static attribute, fixed at element-creation time. -->
<iframe sandbox="allow-scripts" [src]="trustedEmbedUrl"></iframe>
```

```html
<!-- Conditional rendering of distinct static configurations. -->
@if (isTrustedPartner) {
  <iframe sandbox="allow-scripts allow-same-origin" [src]="trustedEmbedUrl"></iframe>
} @else {
  <iframe sandbox="allow-scripts" [src]="trustedEmbedUrl"></iframe>
}
```

Anti-pattern (dynamic binding — do not approve):

```html
<!-- userSandbox may originate from a per-tenant config value; even if
     NG0910 is not currently thrown in this environment, the sandbox's
     effective value can be influenced by that input at runtime. -->
<iframe [attr.sandbox]="userSandbox" [src]="trustedEmbedUrl"></iframe>
```

## Verification targets

- Grep `<iframe>` elements for `[sandbox]`, `[attr.sandbox]`, `[allow]`, `[attr.allow]`, `[credentialless]`, `[attr.credentialless]`, `[csp]`, `[attr.csp]`, `[referrerPolicy]`, `[attr.referrerPolicy]`, `[fetchPriority]`, and `[attr.fetchPriority]`.
- For each match, trace the bound expression backward to determine whether it is a fixed compile-time constant or reachable from user-influenced input (query params, tenant config editable by end users, form state).
- Grep for `ElementRef`-based manual attribute manipulation on iframe elements, which can reintroduce the same dynamic-binding risk outside Angular's compiler-enforced static-attribute check.

# DomSanitizer Bypass Calls and [innerHTML] Bindings

Use this reference only when the review scope includes a `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, or `bypassSecurityTrustResourceUrl` call, or an `[innerHTML]` binding. The OWASP XSS citation below is loaded only when a finding is actually present — do not cite it preemptively in a review that has no finding.

## What people get wrong

The naive assumption is:

> "I called `bypassSecurityTrustHtml`, so I must have already decided this content is safe — the method name itself is my proof of review."

Wrong. The bypass method's name documents *intent* to skip sanitization, not that the argument was actually checked. The recurring real-world failure is a bypass call added to silence Angular's sanitizer error during development, with the "we'll add validation later" step never landing, or a bypass call whose argument source changes in a later refactor (a static string swapped for a computed value fed by an API response) without anyone re-reviewing the call site.

## Officially grounded rules

Angular's own source (`repo evidence` via Context7 `/angular/angular`, `packages/platform-browser/src/security/dom_sanitization_service.ts`) confirms the mechanism directly:

- **`bypassSecurityTrustHtml()` disables Angular's XSS sanitization for the value it wraps.** It marks a string as trusted `SafeHtml`, which causes `sanitize()` to skip the HTML sanitizer entirely and return the value as-is. `bypassSecurityTrustUrl()` and `bypassSecurityTrustResourceUrl()` do the equivalent for URL and resource-URL contexts.
- **Property bindings like `[innerHTML]` accept a compiler-added sanitizer function.** `setDomProperty()` (in `packages/core/src/render3/instructions/shared.ts`) only calls a sanitizer when one is present — "it is assumed that the sanitizer is only added when the compiler determines that the property is risky." Without a sanitizer function reaching that call (which happens whenever a `Safe*` value from a bypass call is passed, since `sanitize()` unwraps it unchanged), the raw value is set directly via `renderer.setProperty()`.
- **Text interpolation is a structurally different, safer path.** `updateTextNode()` calls `renderer.setValue()` on a text node — a text node never parses HTML, so interpolated content cannot execute as markup or script regardless of its contents. This is why interpolation needs no sanitizer at all, and why it is the default recommendation whenever raw HTML rendering is not actually required.
- **`_sanitizeHtml()` (`packages/core/src/sanitization/html_sanitizer.ts`) is the actual sanitizer** invoked when no bypass has occurred: it parses the HTML into an inert DOM tree, strips disallowed elements/attributes against an allowlist, and repeats parsing to catch mutation-XSS (mXSS) auto-correction attacks. This is the protection a bypass call routes around entirely.

## Non-negotiable design rules

### 1. Trace the full origin-to-sink path before judging a bypass call or [innerHTML] binding

Do not evaluate `sanitizer.bypassSecurityTrustHtml(someVar)` or `[innerHTML]="someVar"` in isolation. Follow `someVar` backward: is it a literal string in the component? An `@Input()`? A value derived from a service call? An API response that itself echoes content any user (not necessarily the current one) previously submitted? The finding depends on where that trace terminates, not on the call/binding syntax alone.

### 2. The bypass call's existence is not evidence the argument was validated

A `bypassSecurityTrustHtml`/`bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` call is an intentional escape hatch by design — its presence proves a developer wanted to skip sanitization, not that they checked the value first. Only a validation or sanitization step visibly present *before* the bypass call on that exact path clears the finding.

### 3. A sanitizer call elsewhere in the codebase does not clear a specific [innerHTML] finding

If the trace reveals user-reachable input reaching an `[innerHTML]` binding, the only thing that clears the finding is a named sanitizer call (e.g., `DomSanitizer.sanitize(SecurityContext.HTML, ...)`, or a project-specific equivalent such as DOMPurify) visibly present on that exact path. "This codebase has a sanitize utility used elsewhere" is not evidence the specific path under review calls it.

### 4. Third-party API responses are not automatically trusted

An API response is not "safe by default" just because it did not come directly from the current request's form input. If the API itself stores and echoes content that any user previously submitted (a comment system, a CMS with contributor accounts, a product-review feed), that response is user-reachable input for this review's purposes.

### 5. URL-context bypasses need scheme validation, not HTML sanitization

`bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl` are a distinct injection surface from `bypassSecurityTrustHtml` — do not conflate the fixes. The correct control before a URL-context bypass is scheme validation (an allowlist accepting only `http:`/`https:`/`mailto:` as appropriate, rejecting `javascript:` and other schemes), not HTML sanitization.

## Minimal safe implementation patterns

```ts
import { Component, Input } from '@angular/core';

@Component({
  selector: 'app-comment',
  // Text interpolation never sets innerHTML and needs no sanitizer.
  template: `<div>{{ userComment }}</div>`,
})
export class CommentComponent {
  @Input() userComment = '';
}
```

```html
<!-- A named sanitizer call sits directly on the path between the
     untrusted field and the binding. -->
<div [innerHTML]="sanitizer.sanitize(userBio)"></div>
```

Anti-pattern (untraced bypass call — do not approve):

```ts
// userComment comes from a profile API that echoes user-submitted text.
// No validation anywhere between the API response and this bypass call.
this.trustedComment = this.sanitizer.bypassSecurityTrustHtml(this.userComment);
```

## Adversarial checklist

Before clearing a bypass call or `[innerHTML]` binding, answer these:

- What is the literal origin of the bound value — a template literal, an `@Input()`, a service call result, or an API response?
- Does any point along that trace involve content any user (current or otherwise) previously submitted?
- Is there a named sanitizer or validation call visible on the exact path traced, or only "we sanitize somewhere in this codebase"?
- Could a later code change (a refactor that swaps the data source, or a new field added to an existing API response) reach this same call or binding without re-triggering a security review?

If any answer is unclear or reveals a gap, the finding is HIGH — do not soften it to "worth double-checking."

## OWASP grounding (load only when a finding is present)

Cross-Site Scripting (XSS) is the general vulnerability class that an unvalidated bypass call or unsanitized `[innerHTML]` binding produces: an attacker-controlled or attacker-influenced string is rendered as live HTML/script in another user's browser session. The OWASP XSS reference and OWASP Top Ten (both listed in this skill's `official_docs`) provide the vendor-neutral grounding for why this defect class is treated as HIGH severity by default — it typically enables session/token theft, credential harvesting via injected forms, or full account takeover in the victim's authenticated context. Cite these only in the specific finding write-up for a confirmed or suspected defect, not as boilerplate in every review.

## Verification targets

- Grep component and template source for `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, `bypassSecurityTrustResourceUrl`, `bypassSecurityTrustScript`, and `bypassSecurityTrustStyle`.
- Grep templates for `[innerHTML]` and enumerate every match.
- For each match, grep backward through the component's `@Input()`s, service injections, and any imported store/composable for the value's origin.
- Grep for a `DomSanitizer.sanitize(` call (or an equivalent project-specific sanitizer utility) and confirm its call site is on the traced path, not merely present in the file or module.

# Review Workflow and Findings Contract

Use this reference for the step-by-step review procedure and the required output shape. Load the other two references only for the specific defect class the component or template under review actually raises.

## Prerequisites

- Read the component's imports to confirm whether `DomSanitizer` (from `@angular/platform-browser`) is in use. Do not assume a bypass call exists without confirming the import and the call site.
- Identify the Angular major version in use (`package.json` — `@angular/core`) — sanitizer internals and the NG0910 check are current-Angular behavior; note explicitly if reviewing a much older major where behavior may differ, and label the claim accordingly.

## Workflow

1. **Locate every `DomSanitizer` bypass call.** Grep for `bypassSecurityTrustHtml`, `bypassSecurityTrustUrl`, `bypassSecurityTrustResourceUrl`, `bypassSecurityTrustScript`, and `bypassSecurityTrustStyle`. For each, trace the argument backward through props/`@Input()`s, computed getters, service calls, and API responses to its origin.
2. **Locate every `[innerHTML]` binding.** For each, trace its bound expression the same way. Determine whether the origin includes user-reachable input (route params, query strings, request bodies, or a third-party API response that itself echoes user input) and whether a named sanitizer call (`DomSanitizer.sanitize(SecurityContext.HTML, ...)` or an equivalent) sits on that exact path.
3. **Locate every dynamically bound iframe security attribute.** Grep for `[attr.sandbox]`, `[sandbox]`, `[attr.allow]`, `[allow]`, `[attr.credentialless]`, `[credentialless]`, `[attr.csp]`, `[attr.referrerPolicy]`, and `[attr.fetchPriority]` on `<iframe>` elements (including via a directive's host bindings). See `references/iframe-security-attributes.md` for the decision tree.
4. **Locate every dynamic `[href]`/`[src]` binding fed by `bypassSecurityTrustUrl`/`bypassSecurityTrustResourceUrl`.** Check for scheme validation (an allowlist rejecting `javascript:` and other non-`http(s)` schemes) on the path before the bypass call.
5. **Produce ranked findings** using the output contract below.

## Decision tree

- A bypass call's traced argument includes user-reachable input and no validation/sanitization occurs on that exact path before the call → **HIGH** finding, XSS or URL-injection depending on the bypass method. Do not accept "we validate elsewhere" — the trace must show the check on the specific path reviewed.
- A bypass call's traced argument is fully origin-controlled with no user-reachable input anywhere in the trace (e.g., a static, developer-authored HTML fragment with no user-submission path) → not a finding, but state this explicitly in the output rather than silently omitting the call site.
- An `[innerHTML]` binding's traced source includes user-reachable input and no sanitizer call is present on that exact path → **HIGH** finding, XSS.
- An `[innerHTML]` binding's traced source is fully origin-controlled → not a finding, stated explicitly.
- Any security-sensitive iframe attribute (`sandbox`, `allow`, `allowFullscreen`, `referrerPolicy`, `csp`, `fetchPriority`, `credentialless`) is bound dynamically (property or `attr.` binding) rather than set as a static attribute → **MEDIUM-to-HIGH** finding depending on whether the bound value can be influenced by user-reachable input, regardless of whether NG0910 is currently thrown in the environment reviewed.
- A dynamic `[href]`/`[src]` fed through a bypass call has no scheme allowlist on the path before the bypass → **MEDIUM-to-HIGH** finding depending on reachability (public unauthenticated surface vs. requiring an authenticated session to trigger).

## Output contract

Every response from this skill must return:

1. **Scope** — the component(s), template binding(s), and/or `DomSanitizer` call site(s) reviewed.
2. **Ranked findings** — each with file:line, defect category (`xss`, `url-injection`, or `iframe-sandbox-escape`), the concrete data-flow trace naming every hop from origin to sink, and a fix sketch matching Angular's documented pattern.
3. **Validation/sanitizer status per finding** — an explicit statement of whether validation or sanitization is present on the traced path; never infer one exists.
4. **Evidence level per finding** — `repo evidence`, `documentation-based`, or `inference`. Label structural risk findings as structural risk explicitly — do not imply confirmed exploitation without live evidence.
5. **Verdict** — approve / approve-with-notes / block.
6. **Open questions or out-of-scope items** — e.g., "confirming actual exploitation requires a live payload test in a running browser session, not static review," or "hydration-mismatch risk in this same file is out of scope — recommend `angular-ssr-hydration-review` if relevant."

## When to push back

Push back if the user asks to:

- approve a bypass call because "we validate elsewhere in the app" without a validation/sanitizer call visible on the specific traced path — that is not evidence, it is an assumption,
- treat a bound `[attr.sandbox]`/`[sandbox]` as acceptable because "NG0910 didn't fire in our environment" — a suppressed or unhit dev-mode check does not make the dynamic-binding pattern safe in production,
- downgrade an untraced `[innerHTML]` finding to informational because "it's probably fine" — this skill's default is HIGH for exactly this class of unproven claim,
- skip the review because "DomSanitizer bypass calls are always intentional, so they must already be safe" — the bypass APIs are intentional escape hatches from sanitization, not proof the argument was validated before the call.