当Chrome扩展通过内容脚本注入Web组件时，某些网站可能因TrustedType策略而阻止innerHTML操作，导致Web组件无法正常渲染。本文将指导如何利用Chrome的declarativeNetRequest API修改目标网站的Content-Security-Policy响应头，以绕过TrustedType限制，确保Web组件的顺利注入和渲染。
理解TrustedType错误及其影响
在现代web开发中，浏览器引入了trustedtype api作为一项重要的安全机制，旨在帮助开发者防止跨站脚本（xss）攻击。当页面的content-security-policy (csp) 响应头中包含 require-trusted-types-for ‘script’ 指令时，任何尝试将字符串直接赋值给dom元素的innerhtml、outerhtml、insertadjacenthtml等属性的操作，都必须使用trustedhtml、trustedscript或trustedscripturl等trustedtype对象。如果尝试直接使用普通字符串，浏览器将抛出trustedtype错误，例如failed to set the ‘innerhtml’ property on ‘element’: this document requires ‘trustedhtml。
对于使用Stencil等Web组件库的开发者而言，这可能成为一个挑战。这些库在内部实现中常常会利用innerHTML等属性来渲染组件内容。当尝试通过Chrome扩展的内容脚本将这些组件注入到启用了严格TrustedType策略的网站（如bard.google.com）时，即使注入了所有必要的脚本，也会因为组件库内部对innerHTML的使用而触发TrustedType错误，导致组件无法正常显示。传统的尝试，例如在内容脚本中实现window.trustedTypes.createPolicy，通常无法解决此问题，因为TrustedType策略是在页面加载时由CSP头强制执行的，且策略的创建和管理有严格的沙盒限制。
解决方案：利用declarativeNetRequest修改CSP
为了解决这一问题，我们可以利用Chrome扩展的declarativeNetRequest API。这个API允许扩展在网络请求到达目标服务器或服务器响应返回给浏览器之前，以声明式的方式拦截和修改网络请求或响应。关键在于，declarativeNetRequest在浏览器网络栈的较低层级工作，因此可以在内容脚本执行之前就修改HTTP响应头，从而绕过TrustedType策略的强制执行。
具体而言，我们可以通过declarativeNetRequest API来移除目标网站响应头中的Content-Security-Policy，或者至少移除其中与TrustedType相关的require-trusted-types-for ‘script’指令。通过移除整个CSP头是最直接且通常最有效的方法，可以确保Web组件的innerHTML操作不再受TrustedType的限制。
实现步骤与示例代码
以下是如何使用declarativeNetRequest来移除特定网站CSP头的实现步骤：
在manifest.json中声明权限：首先，你的Chrome扩展需要在manifest.json文件中声明declarativeNetRequest权限。
{ "manifest_version": 3, "name": "Web Component Injector", "version": "1.0", "permissions": [ "declarativeNetRequest" ], "host_permissions": [ "https://bard.google.com/*" // 或者你需要注入组件的所有网站 ], "background": { "service_worker": "background.js" } // ... 其他配置}
host_permissions是必要的，因为它定义了你的扩展可以影响哪些URL。
在background.js中设置规则：在扩展的Service Worker (例如background.js) 中，使用chrome.runtime.onInstalled监听器来设置declarativeNetRequest规则。这样可以确保规则在扩展安装或更新时被应用。
// background.jschrome.runtime.onInstalled.addListener(() => { chrome.declarativeNetRequest.updateSessionRules({ removeRuleIds: [99], // 移除之前可能存在的ID为99的规则 addRules: [{ id: 99, // 规则的唯一ID priority: 1, // 规则优先级 action: { type: 'modifyHeaders', // 动作类型：修改头部 responseHeaders: [ { header: 'Content-Security-Policy', // 要修改的头部名称 operation: 'remove' // 操作：移除该头部 } ], }, condition: { urlFilter: 'https://bard.google.com/*', // 目标URL过滤器 resourceTypes: ['main_frame'] // 资源类型：只对主框架文档生效 } }] }); console.log('CSP removal rule applied for bard.google.com');});
代码解释：
removeRuleIds: [99]：在添加新规则之前，先尝试移除ID为99的现有规则，以避免重复或冲突。addRules：一个包含要添加规则的数组。id: 99：为这条规则指定一个唯一的ID，便于管理。priority: 1：规则的优先级，数值越大优先级越高。action：定义了当规则条件满足时要执行的操作。type: ‘modifyHeaders’：表示我们将修改HTTP头部。responseHeaders：一个数组，定义了对响应头部的具体修改。header: ‘Content-Security-Policy’：指定我们要操作的头部是Content-Security-Policy。operation: ‘remove’：指示浏览器从响应中完全移除这个头部。condition：定义了规则何时触发。urlFilter: ‘https://bard.google.com/*’：这是一个URL过滤器，表示只有当请求的URL匹配这个模式时，规则才会生效。这里我们针对bard.google.com下的所有路径。resourceTypes: [‘main_frame’]：指定规则只对主框架的导航请求生效，而不是对子资源（如图片、脚本、CSS等）的请求。这有助于将规则的作用范围限制在主要页面加载上。
注意事项
权限声明： 务必在manifest.json中正确声明declarativeNetRequest和host_permissions。如果缺少这些权限，规则将无法生效。规则作用域： urlFilter和resourceTypes的设置至关重要。精确地定义它们可以避免不必要地修改其他网站或资源。过度宽泛的规则可能导致意外行为。安全性考量： 移除Content-Security-Policy是一个强力操作，它会削弱目标网站的安全防护，使其更容易受到XSS等攻击。作为扩展开发者，应充分理解其潜在风险，并确保这种操作仅在用户明确知情或特定、受控的环境下进行。规则生命周期： updateSessionRules创建的规则是会话规则，它们在浏览器会话结束后（即浏览器完全关闭并重新启动后）会被清除。如果需要永久规则，应使用updateStaticRules。对于大多数开发和测试场景，会话规则已足够。调试： 在开发过程中，可以使用Chrome浏览器的开发者工具，切换到“网络”选项卡，观察目标网站的响应头部，以验证CSP是否已被成功移除。
总结
通过declarativeNetRequest API，Chrome扩展能够有效地解决Web组件注入过程中遇到的TrustedType错误。通过在网络层级修改Content-Security-Policy响应头，我们可以绕过浏览器强制执行的TrustedType限制，从而确保Stencill等Web组件库能够顺利地在目标网站上渲染。然而，鉴于此操作对网站安全性的潜在影响，开发者在使用时务必谨慎，并充分考虑其合理性和必要性。
以上就是Chrome扩展注入Web组件：TrustedType错误解决方案的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1525010.html
微信扫一扫 
支付宝扫一扫 
