解释 请从一开始就注意到，通过“注入脚本”，“扩展代码”和“内容脚本”，我将使用此question的优秀第一个答案中提供的定义。
假设：如果我在注入的脚本（在Web区域中）直接执行机密信息，那么处理机密信息的安全性就低于我在内容脚本和扩展名的chrome：//区域内执行机密信息的安全性码。因此，我应该使用消息传递将机密信息从Web区域发送到chrome：//区域，以便进行处理。
问题：我正在构建一个Google Chrome扩展程序，我需要对从我注入的脚本派生的敏感用户数据运行一些操作。有问题的数据是保密的，我必须尽我所能确保除了扩展用户之外，任何人都看不到它，直到我对它进行操作。 3种技术（定义如下）中可用于在注入的脚本和扩展代码/内容脚本之间传递消息，这最适合此目的？
我对可用于在注入的脚本和扩展代码/内容脚本之间传递数据的3种不同技术的理解：
对于在注入的脚本和扩展代码（例如后台页面）之间传递消息，可以使用chrome.runtime API。
对于在注入的脚本和内容脚本之间传递消息，可以使用window.postMessage。
在注入的脚本和内容脚本之间传递消息的另一种方法是通过document.dispatchEvent(CustomEvent)。
我的理解是方法1不能用于注入脚本和内容脚本之间的消息传递，而方法2和3.不能用于注入脚本和扩展代码之间的消息传递（除非消息被转发）通过内容脚本，例如，背景页面。）
答案 0 :(得分：5)
虽然在后台页面/内容脚本中运行的代码非常孤立，但只要将脚本注入页面上下文，您就会进入Wild West。任何扩展和页面本身都可以访问该上下文，并可以影响代码的执行方式。
例如，某些扩展可以覆盖chrome.runtime.sendMessage以发送消息并记录它。这需要认真考虑 - 可能你已经输了。
也就是说，方法1比2/3更难打破 - 正如所解释的那样，攻击者扩展需要直接改变页面上下文以进行干扰，而在DOM事件的情况下，它可以从安全性中听取它们其内容脚本 - 事件被广播到所有内容脚本上下文。
假设您也可以为通道使用某种非对称加密技术 - 为注入的脚本提供加密密钥，并将解密密钥保留在特权区域中。这可以保护通信，如果这是截获的唯一内容，但在某些时候，全局上下文中的明文数据存在 - 这可能足以让攻击者脚本提取（那，你，必须假设，在注入脚本之前执行。）