You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"Returns true if value is an instance of TrustedHTML and has an associated data value set, false otherwise."
and there is a note saying this allows to "check if a given object is truly a legitimate Trusted Type object (i.e. it was created via one of the configured policies)".
The CSP spec seems to do something similar but relies on implements instead. In that case we don't need to check if "the object has an associated data". So we the definition could be simplified as follows:
"Returns true if value is implements TrustedHTML".
Browsers don't seem to check the presence of associated data, and I believe perform something that matches "implements":
BTW, I also believe these methods still return true for Trusted Type objects with forget toString mentioned on w3c/webappsec-csp#697 that is Object.assign(policy.createScript("safe"), { toString: () => "unsafe" }). Maybe the note should mention that, maybe we should have tests too...
The text was updated successfully, but these errors were encountered:
BTW, I also believe these methods still return true for Trusted Type objects with forget toString mentioned on w3c/webappsec-csp#697 that is Object.assign(policy.createScript("safe"), { toString: () => "unsafe" }). Maybe the note should mention that, maybe we should have tests too...
A potential security hole for this could be somePolicy.createScript(trustedtypes.isScript(someForgedObject) ? someForgedObject.toString() : "fallback");.
cc @koto @lukewarlow @mbrodesser-Igalia
Initially suggested here: web-platform-tests/wpt#49371 (comment)
See https://w3c.github.io/trusted-types/dist/spec/#dom-trustedtypepolicyfactory-ishtml
"Returns true if value is an instance of TrustedHTML and has an associated data value set, false otherwise."
and there is a note saying this allows to "check if a given object is truly a legitimate Trusted Type object (i.e. it was created via one of the configured policies)".
The CSP spec seems to do something similar but relies on implements instead. In that case we don't need to check if "the object has an associated data". So we the definition could be simplified as follows:
"Returns true if value is implements TrustedHTML".
Browsers don't seem to check the presence of associated data, and I believe perform something that matches "implements":
Chromium: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/trustedtypes/trusted_type_policy_factory.cc;l=301;drc=117bbc5c974e90bd7b28653649b4a59344bb22f0
Firefox: https://searchfox.org/mozilla-central/rev/fb8a1b0beee7dbc1b0a35050ec5c0345f0b09173/dom/security/trusted-types/TrustedTypePolicyFactory.cpp#159
WebKit: https://searchfox.org/wubkat/rev/c3d6184dbe8d3daa73c7c9201ce556cf81e35d3e/Source/WebCore/dom/TrustedTypePolicyFactory.cpp#85
BTW, I also believe these methods still return true for Trusted Type objects with forget toString mentioned on w3c/webappsec-csp#697 that is
Object.assign(policy.createScript("safe"), { toString: () => "unsafe" })
. Maybe the note should mention that, maybe we should have tests too...The text was updated successfully, but these errors were encountered: