I took a deeper look at the implementation and identified two edge-case issues related to how security contexts are merged and resolved for dynamic/generic hosts:

1. Over-sanitization of benign custom properties on generic hosts

Because calcHostBindingSecurityContexts merges contexts across all possible DOM elements when a directive's selector doesn't specify a concrete tag, a property like [attr.data] (which is a RESOURCE_URL on <object> but just NONE on a generic <div>) results in a context array of [SecurityContext.RESOURCE_URL, SecurityContext.NONE].

The isUrlOrResourceUrlSecurityContext function correctly evaluates this to true and instructs the compiler to emit the ɵɵsanitizeUrlOrResourceUrl runtime sanitizer.
However, at runtime, if the concrete element happens to be a <div>, getUrlSanitizer in sanitization.ts falls back to ɵɵsanitizeUrl (because div is not in the RESOURCE_MAP for data). As a result, a completely safe string bound to a custom [attr.data] on a <div> (e.g., 'javascript:something') will be unexpectedly over-sanitized and prefixed with unsafe:, mutating benign data attributes.

2. Inconsistent fallback handling for mixed non-URL contexts

In calcHostBindingSecurityContexts, the fallback logic drops the SecurityContext.NONE context if other contexts are present:

  if (
    (hasConcreteHostNoneContext && concreteHostNonNoneCount > 0) ||
    // ...
  ) {
    return concreteHostNonNoneContexts;
  }

If a property requires a completely different sanitizer (like [attr.srcdoc] which maps to SecurityContext.HTML on an iframe and NONE elsewhere), the compiler drops NONE and correctly hardcodes ɵɵsanitizeHtml for the binding. While this works safely for srcdoc, it silently ignores the fact that the property is supposed to be unsanitized (NONE) on other tags, leading to unconditional HTML sanitization across all tags.

Additionally, if a custom schema or future DOM property mapped an attribute to [SecurityContext.RESOURCE_URL, SecurityContext.SCRIPT], isUrlOrResourceUrlSecurityContext would evaluate to false and cause getOnlySecurityContext() to throw a compilation error, as it doesn't gracefully handle mixed contexts outside of the hardcoded URL/RESOURCE_URL scenario.

Nice work here! The logic looks good, but I’d like to spend a bit more time reviewing the unit tests to see if we can make them easier to follow, I can be just me, but I personally am having quite a hard time to follow them.

I also noticed quite a bit of redundant code in sanitization.ts. To save some time from going back and forth, I'll push a quick commit to your branch to clean that up.

LGTM

Reviewed-for: fw-security