TrustedTypesAPI防止XSS攻击解析

Trusted Types API 并非万能的 XSS 防御银弹，而是一套需精密配置的运行时强制机制：它通过 CSP 响应头（必须包含 `require-trusted-types-for 'script'` 和显式声明的 `trusted-types` 策略名）激活浏览器拦截能力，严格约束 `innerHTML`、`insertAdjacentHTML` 等高危 sink 只能接收由合规策略函数返回的 `TrustedHTML` 对象——这意味着哪怕一行未过滤的字符串赋值也会被阻断，但前提是策略本身不写错（如禁用字符串拼接、正则过滤或 `toString()` 降级），且覆盖所有潜在入口（包括框架底层调用和易被忽视的 `document.write`、`outerHTML` 等）；真正安全的实践不是堆砌客户端逻辑，而是优先用 `textContent` 规避风险，必须渲染 HTML 时则依托 DOMPurify 等成熟库生成可信类型，并将净化逻辑彻底移出应用代码——因为 Trusted Types 从不检查你“怎么造出”可信对象，只校验你“交出来的是不是”可信对象，稍有疏忽，策略本身就会沦为新的 XSS 温床。

不能“彻底杜绝”，但能强制拦截所有未经过滤的 innerHTML 赋值——前提是 CSP 头配对生效、策略覆盖到位、且不绕过类型检查。

require-trusted-types-for 'script' 必须通过 HTTP 响应头启用

仅在 JS 里调用 trustedTypes.createPolicy() 完全无效。浏览器只在收到 HTTP 头后才开始拦截 innerHTML 等操作。

• Content-Security-Policy: require-trusted-types-for 'script'; trusted-types default; 是最小可行配置
• trusted-types 后必须显式列出策略名（如 default），否则 trustedTypes.createPolicy('default', {...}) 创建失败，回退为宽松模式
• meta 标签无法设置 require-trusted-types-for，必须走 HTTP 响应头；开发期可用 Content-Security-Policy-Report-Only 先收集违规日志
• 漏掉任一指令，整个机制静默失效：比如只加 trusted-types default 但没加 require-trusted-types-for 'script'，el.innerHTML = '' 仍会执行

createPolicy 返回的函数必须返回 TrustedHTML，不能 return 字符串

策略函数体里写 return '

• 正确写法是只做最小必要包装，例如用 DOMPurify：return DOMPurify.sanitize(input, { RETURN_TRUSTED_TYPE: true });
• 禁止在策略内写正则过滤、HTML 解析、白名单拼接等逻辑：性能差、绕过成本低、维护难
• 不要复用同一策略处理多种 sink（如既用于 innerHTML 又用于 location.href），职责分离更可控
• 策略名必须与 CSP 中声明的一致，大小写敏感；default 是特殊名称，浏览器在找不到匹配策略时会尝试调用它

innerHTML 不是唯一要管的 sink，框架调用也可能逃逸

攻击者会主动寻找未被策略覆盖的入口。以下 API 同样触发 TrustedHTML 检查，但容易被忽略：

• el.insertAdjacentHTML('beforeend', html) —— 和 innerHTML 同级危险，必须走同一策略
• document.write(html)、document.writeln(html) —— 已淘汰但仍存在，需策略覆盖
• el.outerHTML = html —— 同样受控，但部分旧版 Safari 对 shadowRoot.innerHTML 支持不全
• React/Vue 等框架内部调用这些 API 时，需确认版本是否声明兼容 Trusted Types；例如 React 18.3+ 开始支持 useTrustedTypes 配置，旧版本可能绕过
• el.setAttribute('onload', ...) 不受控，但 el.setAttribute('innerHTML', ...) 是无效属性名，不会触发拦截，属于策略外挂

textContent 是默认安全出口，别为了“动态 HTML”硬上 innerHTML

90% 的场景其实不需要插入 HTML：用户昵称、文章摘要、状态标签等，用 textContent 或 innerText 即可，完全绕过 Trusted Types 复杂性，且零风险。

• 必须插 HTML 时，优先考虑预编译模板（如 HTMX + 服务端 sanitize）或服务端渲染，而非客户端拼接
• 若真需客户端生成，用 DOMPurify.sanitize(..., {RETURN_TRUSTED_TYPE:true}) + 显式策略封装，而不是自己写“简单转义”
• 避免把 TrustedHTML 对象再 toString() 后传给其他函数——这等于放弃类型保护，且部分浏览器会抛错
• 注意 location.href 赋值含 javascript: 时也受控，但 location.assign() 接收 TrustedURL 实例才放行，不是 TrustedHTML

最常被忽略的点：策略函数本身不能包含 eval、new Function、setTimeout(string)，也不能拼接字符串后直接 return；这类写法会让策略变成 XSS 入口本身。Trusted Types 不是魔法，它只校验“你交出来的对象是不是 Trusted 类型”，不校验“你造这个对象的过程安不安全”。

今天关于《TrustedTypesAPI防止XSS攻击解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！