Thanks for the contribution. We agree there is a security concern here, but this implementation isn't the correct approach. Refer to PR #68591 for more context.

I’ll treat this PR as superseded by #68591. My implementation handled this as a narrow rejection in the i18n metadata path, while #68591 appears to address the broader root cause by resolving i18n static attributes through Angular’s DOM security schema and applying the correct sanitizer or validateAttribute path.

For disclosure traceability, I understand this PR was closed because the proposed implementation was not the desired fix approach, not because the underlying issue was invalid. Your comment confirms there is a security concern here.

The concrete case covered by this PR was translated iframe policy attributes such as sandbox, csp, referrerpolicy, and allow. Those attributes are security-sensitive because changing them can relax iframe sandboxing, CSP, referrer leakage, or Permissions Policy controls. The issue was that static translated i18n attributes could bypass the same framework security handling that Angular applies to equivalent security-sensitive bindings.

I’ll reference #68591 as the canonical maintainer-owned remediation path for this issue.

The concrete case covered by this PR was translated iframe policy attributes such as sandbox, csp, referrerpolicy, and allow. Those attributes are security-sensitive because changing them can relax iframe sandboxing, CSP, referrer leakage, or Permissions Policy controls. The issue was that static translated i18n attributes could bypass the same framework security handling that Angular applies to equivalent security-sensitive bindings.

I understand, and we will discuss this further with the team since this issue extends beyond iframes to all security-sensitive attributes.

While we agree on the issues, our concerns lies in the implementation strategy. We should avoid fragmented logic and instead rely on a centralized validator within the DOM schema, if necessary, implement a stricter validator to prevent static values from being overridden. We'll finalize the approach during our internal team discussion.

Thanks @alan-agius4 , I reviewed #68591 locally and I agree this is the right hardening direction.

The main improvement is that the i18n decision becomes schema-driven instead of being tied to each individual reported attribute. That matches the invariant behind the related reports:

translated static i18n attributes should not bypass the sanitizer/validator path Angular applies to the same security-sensitive tag/attribute pair elsewhere.

The security-context mapping in #68591 looks correct to me:

• SecurityContext.URL -> sanitize translated values.
• SecurityContext.RESOURCE_URL -> route through sanitizeResourceUrl, so untrusted translated strings are not accepted as executable resource URLs.
• SecurityContext.ATTRIBUTE_NO_BINDING -> route through validateAttribute, covering iframe policy attributes and SVG animation retargeting attributes.
• Non-security-sensitive translated attributes remain supported.

A couple of hardening details may be worth keeping in the final version:

1. Namespace normalization should be consistent anywhere SECURITY_SCHEMA is queried. The compiler-side registry now strips :svg: / :math:, but the runtime i18n schema lookup appears to lower-case the tag name and query the schema directly. If that runtime path can receive namespace-prefixed tags such as :svg:set or :svg:script, it should normalize them as well or have regression coverage proving they cannot reach that shape.

2. Since feat(core): support prefix-insensitive DOM schema lookups and compile-time i18n attribute validation #68591 introduces a core-side copy of SECURITY_SCHEMA, it may be useful to add a parity/regression test so the compiler and core schemas do not drift over time. A mismatch there would recreate the same class of issue for future security-sensitive attributes.

3. For RESOURCE_URL and ATTRIBUTE_NO_BINDING, the final behavior should fail closed. RESOURCE_URL translations should not become trusted executable resource URLs, and ATTRIBUTE_NO_BINDING translations should not be able to weaken iframe policy attributes or SVG animation retargeting attributes.

The current tests already map well to the disclosed cases: URL attributes, SVG script ResourceURL attributes, iframe policy attributes, SVG SMIL retargeting, and a non-sensitive negative control. If namespace-prefixed SVG/MathML coverage is also included, #68591 looks like the correct maintainer-owned remediation path for the related security reports.

For context, this appears to cover the concrete cases I reported in #68557, #68559, #68560, and #68580. My priority here is to make sure the hardening is complete and robust; if there is anything else I can validate or adjust from the reporter side, happy to help.