客户端存储JWT至LocalStorage前的加密方案及代码保护问询

攻击者能否通过查看JS代码获取密钥构建逻辑？ #

答案是肯定的。前端JavaScript代码最终都会被浏览器解析执行，攻击者可通过开发者工具、代码反混淆工具轻松获取或还原源码——哪怕你对代码做了压缩处理，有经验的逆向人员也能逐步梳理出密钥构建逻辑。更关键的是，你用来生成密钥的设备特征（浏览器名称、版本、设备信息等）本身就是公开可获取的，一旦逻辑被还原，攻击者只需在相同环境（或模拟相同环境）下就能生成相同密钥，进而解密LocalStorage中的令牌。

前端可采用的逻辑隐藏技术 #

以下几种方法能提升逆向难度，但需明确：所有前端隐藏手段都只是提高攻击成本，无法实现绝对安全。

• 代码混淆：使用Terser、Obfuscator.io等工具对核心逻辑代码进行混淆，包括重命名变量/函数、插入冗余代码、打乱控制流，让源码可读性大幅降低。注意平衡混淆程度，避免影响应用性能。
• 关键字符串加密：将密钥构建逻辑中用到的特征字段名、哈希算法标识等关键字符串加密存储，运行时动态解密后再使用，防止攻击者通过字符串搜索快速定位核心逻辑。
• 动态分片加载：把密钥生成、令牌加解密的核心逻辑拆分成多个小模块，通过import()异步加载，避免核心逻辑一次性暴露在主脚本中。
• WebAssembly（Wasm）迁移：将核心加密/密钥生成逻辑用C、C++或Rust编写，编译成Wasm二进制文件后在前端调用。Wasm的二进制代码比JavaScript更难逆向，能显著提升逻辑隐蔽性。
• 控制流扁平化：把线性的逻辑流程拆分成大量嵌套的条件判断、循环结构，打乱原有执行顺序，让攻击者难以快速梳理出核心逻辑路径。

最后补充：如果你的应用对安全性要求极高，优先考虑重新评估令牌存储方案——比如尝试使用HttpOnly Cookie（若业务场景允许），或者采用短有效期access token+高频刷新的机制，从根源降低令牌泄露的风险。

内容的提问来源于stack exchange，提问作者Elshad Shabanov