不要信任浏览器,而是采取措施对用户进行身份验证。因此,在这种情况下,您可以要求您输入用于与服务器通信的密码。
您的 Google 扩展程序会要求您在尝试使用 AJAX 与您的服务器通信之前输入密码。
请注意,您应该建立保护自己免受暴力攻击的方法。因此,如果有超过一些错误密码等,请执行诸如锁定所有内容之类的操作。
你也可以考虑使用密码来简单地解密 XHR 的目的地,但如果你走这条路,你应该非常小心地存储它,因为这将在离线时被暴力破解。
编辑
试图锁定一个 API 以便只有一个应用程序可以使用它是不切实际的,在技术上也是不可能的,所以你唯一的希望就是使用 API 对用户进行身份验证,而不管他使用的是什么访问软件. 您可以让用户签署一项协议,在法律上将他们限制为仅限您的扩展程序,但我怀疑这将在很大程度上无法执行,并且会占用您跟踪滥用者的时间。
如果您不希望未经授权的人知道 API 在哪里,您可以使用带外机制执行身份验证:通过电话、电子邮件、SMS,或者简单地说,另一个将授予用户密码或令牌的 API对您的 API 的请求必须随附。
在此带外过程中,您还可以授予用户一个唯一的 URI(API 访问点),该 URI 仅在每个经过身份验证的会话中有效(https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0 /,例如)。在其他 URI 上对您的服务器的任何请求都将不起作用。但是,这在理论上与使用相同的 API 访问点并拥有一个好的密码并没有太大区别。它只是改变了架构中将执行身份验证和/或授权检查的位置数量。
<aside>
我的投票是将授权/身份验证点的数量减少到尽可能少,这样您就可以花更多的时间来纠正一个地方,而不是有多个地方和可能的多个逻辑缺陷或其他可能导致漏洞的事情。</aside>
您还可以探索使用公钥基础设施和/或一次性密码方案或基于设备的令牌生成器等,但最终,您将允许经过身份验证和授权的用户使用您的 API。并且,多亏了 Internet,这将不会长期保持未公开的 URI。
而且,更重要的是,它不会阻止某人自己使用数据。即使采取了所有这些措施,授权用户在将这些数据流式传输到您的扩展程序时收集这些数据也是微不足道的。或者,如果您采用点对点加密,他们可以截屏或对您的代码使用某种形式的 JS 内省,甚至从他们的计算机内存中提取数据。
我知道你在这里寻找灵丹妙药,但它不存在。