在浏览器里分发并执行的 JS/WASM，仍然做不到“真正不可破解”
2025-12-11
先把底线讲清楚
在浏览器里分发并执行的 JS/WASM，仍然做不到“真正不可破解”。
原因没变：代码必须到达用户端并在本地可执行，最终会以明文或可还原的形式出现。所谓“最新手段”，更多是把关键价值转移到远端 + 加强鉴别与追责，而不是让前端本身变成“打不开的黑盒”。这一点至今没有被任何新技术推翻。
2024–2025 的“新东西”，能解决什么、不能解决什么
1) 设备绑定会话（DBSC）
能做：把登录会话硬件绑定（防 cookie/令牌被窃后在别的机器复用），提升盗用成本与滥用追踪能力。Chrome 在 2025 年面向网站推出 DBSC 集成指引，并已在 Workspace 等开始实践与试点。(Chrome for Developers)
不能做：保护你的前端代码机密。它解决的是会话劫持/盗用，而非代码逆向。
2) Private State Tokens（前身 Trust Token）
能做：在不跨站跟踪的前提下携带“可信度”信号，帮助区分真人/机器人、降低欺诈。对抗批量盗刷/脚本化滥用有价值。(Privacy Sandbox)
不能做：仍然不能阻止别人阅读或修改你发到客户端的代码。
3) Android WebView Media Integrity（针对 App 内 WebView）
能做：如果你的前端运行在 Android App 的 WebView 里，可拿到设备/应用完整性信号，让媒体/受限资源只在“合规环境”播放或调用。2024 起面向开发者可用，并有相应的 WebKit/Play Integrity 配置项。(Android Developers Blog)
不能做：这不是开放 Web 的通用解；对普通浏览器页面无效。
4) 机密计算（Confidential Computing）+ 远端证明（Attestation）
能做：把“值钱逻辑/模型/规则/密钥”放到云端 TEE（SGX / SEV-SNP / Nitro 等），用户侧拿不到算法和数据；通过远端证明让调用方确信“只与指定、未被篡改的代码在受硬件隔离环境内交互”。这是今天唯一能“从根上”保护核心的路线。(Duality Technologies)
不能做：仍需设计调用鉴权、限流计费、接口签名等防滥用链路；不能让纯前端离线代码不可逆向。
5) Web Environment Integrity（WEI）现状
结论：作为开放 Web API 的 WEI 已被 Chrome 团队放弃；不要把它当做“未来能封死前端”的抓手。(9to5Google)
如果目标是“实战可售卖、对抗破解”，推荐的2025 版组合拳
方案一：云端托管核心 + 远端证明 + 强鉴权（最稳）
把核心算法/模型上云，跑在 TEE/机密容器里（GCP Confidential Space、Nitro/SEV 等），对外仅暴露最小 API。
启用远端证明：客户端在调用前验证你后端的测量值/证书链，确认代码确实在预期 TEE 内运行。(Google 开发者博客)
通道路由：所有付费功能经由该 API；前端只是 UI 壳。
接口加固：短命令牌 + 请求体签名（HMAC/RSA）+ 速率限制 + 异常检测 + 日志留证（便于法务）。
配套：DBSC 绑定登录态，PST 传递可信度信号，显著降低批量盗用与账号共享套利。(Chrome for Developers)
适用：涉及算法资产/付费能力/数据服务/AI 推理/规则引擎等，要“真防护”只能走这条。
方案二：前端 SDK/框架售卖的“抗性升级版”（能卖、可追责）
当你必须把一部分逻辑下发给客户（B 端嵌入/离线场景）时：
核心逻辑 WASM 化（提升逆向成本），但对真正的逆向者仍非绝对安全。
许可证采用“前端公钥验签 + 在线核验”：证书由你后端私钥签发，前端只放公钥；定期在线校验吊销/并发/域名或硬件绑定。
水印与指纹：每个客户构建变体唯一，可在泄露时溯源。
对运行环境做“软约束”：若运行在 Android WebView，可叠加 Media Integrity 信号；桌面/内网场景配合 OS 证书与代理层签名校验。(Android Developers Blog)
适用：可离线 UI 组件、行业 SDK、可插拔图表/编辑器等，目标是提高破解成本 + 便于追责。
“朋友说都过时了”？——哪些观念需要更新
✅ 新增的“强信号”：DBSC、PST、（Android）WebView Media Integrity 这类环境/会话完整性信号是 2024–2025 年的主线；它们不是加密前端，而是让“盗用/批量滥用”更难与可溯。(Chrome for Developers)
✅ 真正“保密算法”的路径仍然只有把东西放在你控制的机器上，而且现在能加码到机密计算 + 远端证明，这点相较几年前确实是“升级版”的硬保障。(Google 开发者博客)
❌ 期望“前端出现不可破解的加密”：这在开放 Web 的执行模型下依旧不可实现，WEI 也不再是选项。(9to5Google)
给你一套快照式落地清单
产品拆分：把值钱逻辑全部移到 TEE 后端；前端只剩 UI 和最小胶水层。(Google 开发者博客)
调用安全：
登录/会话用 DBSC；
反滥用用 Private State Tokens；
API 层用 短期签名 Token + 限流 + 异常监控。(Chrome for Developers)
B 端/离线补丁：核心路径 WASM 化 + 公钥验签的 License + 水印；若在 Android WebView，再叠 Media Integrity。(Android Developers Blog)
法务与运营：EULA 限定用途与反编译、证据留存（构建哈希/访问日志/水印回溯）。
结论（直话直说）
“不可破解”的前端不存在，这点没被任何“最新技术”推翻。
“真正做到防护”，在 2025 年的现实做法是：机密计算 + 远端证明托管核心能力；浏览器侧用 DBSC/PST 加固账号与流量质量；必要时在 Android WebView 内用 Media Integrity 增强环境信号。
如果你愿意，我可以按你的业务形态（纯 Web / WebView / Electron / B 端 SDK）给出具体的架构图与接口签名/验证示例，把这套组合拳细化到“可直接集成的清单”。
发表评论: