等保测评wgt打包有高危漏洞！

欢迎到专业群（ uni-app 官方技术交流群 1 ） 咨询，群中有相关专业的管理员和群友。

这个问题先说明一下本质原因：wgt 包本质就是 zip 压缩包，解压后可以看到编译后的前端资源（app-service.js 等）属于正常情况，前端代码在任何 App 里都无法做到绝对不可见。accessKey、secretKey 属于服务端敏感凭证，只要写在前端代码里，就一定会随包下发，被扫描出来判定为高危是符合实际的，混淆、加密都只能增加逆向难度，不能根治。

根本解决方案（你的项目已经用了云函数，改造成本很低）：

1. 把前端代码中所有使用 accessKey、secretKey 的逻辑全部移除，这些密钥只保留在云函数代码中。云函数运行在服务端，代码不会下发到客户端，前端通过 uniCloud.callFunction 调用云函数获取处理结果即可。

2. 如果业务场景需要前端直连某个云服务（比如文件直传这类），改为由云函数生成临时凭证或签名再下发给前端使用，前端只拿到短时有效的临时凭证，而不是长期有效的 accessKey、secretKey。

3. 改造完成后重新制作 wgt 包，解压检查 app-service.js 中不再包含这些密钥字符串，再提交等保复测。

关于混淆和加固需要说明：DCloud 提供 js/nvue 文件原生混淆能力，但官方文档明确提示"没有绝对的安全，非常重要的信息，应该保存在服务器而不是前端"，且 uni-app 项目的原生混淆针对的是 nvue 文件，运行期解密也会影响执行性能，所以它只能作为辅助手段，无法解决密钥写在前端的问题。详见 js/nvue 原生混淆文档。

另外，如果后续整包（apk/ipa）送等保测评还会遇到其他检测项，DCloud 有安全加固和等保测评相关业务，可以保障通过上架和测评要求，可参考 App 安全漏洞风险说明。

总结：这个高危漏洞的合规解法就是把密钥从前端代码彻底移除、收敛到云函数中，这是唯一能通过检测的方式，不要依赖混淆或加固来掩盖前端明文密钥。

uniCloud的accessKey、secretKey是客户端使用的配置，只能放在客户端。如果不希望明文出现在你的代码或者wgt内可以按照小助手说的使用原生混淆能力