免责声明：这是一个概念/设计问题，但我希望社区能够足够开放地让我发布它，我自己已经为这个想法奋斗了很长时间，并且非常感谢一些经历过外部对此事的想法。
我构建了一个无人值守的非交互式 JS 客户端，以浏览器扩展的形式在后台运行。
主要限制是：非交互式，据我所知，几乎不可能验证客户端的真实性。
JS 客户端针对 OAUTH 2.0 API 执行获取 POST 请求，目前使用非常经典的硬编码“不在现实生活中使用”client_credential 模型，其中客户端 id 和密钥直接在代码中输入。
尽我所能思考这个概念问题，将其转变为基于证书的令牌声明不会增加情况的安全性，事实上恰恰相反，因为攻击者仍然可以很容易地获取插件源代码，提取证书并冒充扩展发送恶意数据包。
所以基本上我目前的想法是混淆整个获取请求，包括“fetch”关键字本身，使其尽可能困难，并且对于恶意用户获取敏感凭据来说尽可能难以理解。
为了执行这个想法，我为初学者考虑了以下几点：
将主体参数名称的每个字母转换为函数的结果，例如：
"client_secret" = (f^-1 o f)(C) + (g^-1 o g)(L) + ... + (x^-1 o x)(S) 因此，我不会在源代码中编写“C”，而是为每个字母编写 f(“C”)，它看起来像一些复杂的“”“哈希””。
构图不必是附加的，可以分成多行等，以使其更难区分我真正在做什么，但这只是为了说明。
每个参数的值将遵循类似的模式，它们将以密码链结果的形式存储到本地文件中。例如：
"client_id.value" = DES(AES(Blowfish(MycustomfunctionA(MycustomfunctionB...(client_id))))) 然后是“fetch”关键字本身的问题，这会引起任何攻击者的兴趣，目前我还没有一个明确的想法，因为这意味着将代码动态加载到与已经执行的代码相同的上下文中，那时它开始变得有点失控，但在某种程度上仍然很有趣......
所以，是的，这基本上就是我现在的方向，我显然不确定我在做什么，这就是为什么我来询问专业人士是否有更好的方法，更聪明的方法来解决这个问题非常有问题....
感谢大家的耐心/理解。
我的想法：
混淆并不安全。有人最终会弄清楚你在用代码做什么。
您混淆了发送 HTTP 请求的代码。攻击者可以嗅探从您的分机发出的流量。她将从那里获取所有信息，甚至不需要理解您的代码。
也许您应该查看动态客户端注册。每个浏览器扩展实例都会注册为单独的客户端，以便您可以更轻松地控制正在发生的事情（例如阻止可疑客户端）。
基本上，您是对的 - 您应该将从扩展程序传入的所有流量视为潜在恶意，并且后端应该相应地解决该问题。