请教个问题：前端请求加密，通过查看源码还是可以破解，那么加密的意义是什么？

[weekidjoker]

[ohwind]

上面都在说什么？而且前端加密取决于你是怎么加的，加密的是什么东西。如果你是指你请求的数据加密，即使你知道算法，没有密钥或者私钥怎么解密？如果你是指源码加密（混淆），这当然可以被破解，混淆可以增加破解成本，但不意味着百分百防御，你也可以把逻辑扔 WASM 里，当然这也不是一定安全的，所以一切机密的算法和逻辑你应该放在服务器而不是前端。

[xinyu391]

加密解决的是传输过程防止偷窥

[di1012]

防君子不防小人

[laqow]

腾讯轻量云一堆机器蹲着内网监听呢

[lanbatian]

**既然市面上大部分锁都可以在 20 分钟内撬开，那门上装锁是否还有意义？**

如果对数据传输的安全有要求的话，有加密总比没有要强把。

[zpf124]

在使用 https 的情况下，个人对于前端加密是觉得属于脱裤子放屁，但搞支付保险等涉及大钱的东西的时候，合规部门或者等保认证要求加就加呗。

安全评分从 90 变成了 93 对我而言是觉得做与不做差距不大，后端部分属于那 90 分，要么不扣要么直接-90 ，如果后端被破了，那有你这 1 分还是没有都无所谓，所以 最后得分是 90 、93 还是 0 、3 ，这其中的 3 分的部分重要么。

[millet230413]

@duke807 这边知道这个的，并使用这个的看下来没有呢，再写一个 ajax 劫持的 sdk ，基本上没有破解的可能

[zpf124]

@ohwind 前端数据加密的密钥不就是代码里写着的吗，或者是从某些接口可以获取到，只要分析代码就可以做的伪装客户端，最多是使用非对称加密，可以保证中间人无法伪装成后端来欺骗前端，然而 https + 可信 ca 基本上就已经完全防护了中间人了。

[weekidjoker]

@millet230413 我没有写过 wasm ，但是应该也可以反编译吧，所以还是一个花费成本问题？

[ohwind]

@zpf124 伪装客户端你没有任何办法，除非你是给特定的人用的，可以让他们用自己的客户端，否则别人改一下浏览器，就算你混淆也没用。所以我说要看你加密的目的是什么，如果是为了防止中间人偷窥，https 足够用了。如果目的是防止伪装客户端，那基本不可能完全避免，所以行业内的做法都是把涉及到敏感数据的都让你登录完成身份验证，加密过程服务端进行。

[ohwind]

@weekidjoker #49 是的，仅仅是提高了破解成本而已。防破解本身就不是一个简单的问题，更何况是对于本就更容易破解的网页前端。

[blurh11E27]

哈哈哈哈哈

我也做过这个，我也有同样的问题，但是我思考了一下，
公钥 加密后 + ip 加 时间戳 我擦 毫无卵用 好像等于告诉别人 我加密方式 和 公钥？ 最多混淆一下。
还不如 直接简单 md5 加盐

加密 加 ip shi 时间戳 最多也就防止别人抓取后台返回的 token
但源码前端的别人还是能看到 就是 看混淆了吧

[KT0J]

@ohwind

感觉只有你在认真回答。。。

[millet230413]

@weekidjoker wasm 是用 C 语言编写相关功能，然后编译成二进制嵌入到 js 代码中，前端反编译只能看到 C 编译成的二进制文本，而不是 js 的字符文本，当然了，二进制的可执行代码也可以反编译，但是在加了自定义混淆算法后，破解的可能性非常低

[anpho]

增加破解成本。
跟防盗门的锁一样，防破坏时间因为级别不同而有明显的区别。甲级不低于３０分钟，乙级不低于１５分钟，丙级不低于１０分钟，丁级不低于６分钟。

[coolloves]

其实,就好比,gfw 的意义.总有人会施法.

[centralpark]

这就跟 App 加壳一个道理啊，多少年的业界实践，怎么还会有人觉得毫无卵用呢？建议搜一下 jsvmp 、js 补环境等关键词了解一下前端加密给爬虫和灰产带来了多大的痛苦。

不过话说回来，国内多喜欢加密，国外多喜欢风控，一个偏向客户端，一个偏向服务端，这个倒是生态的差异了。

[Perry]

前端请求加密不代表加密是在前端执行的啊。。。后端加密之后发给前端，然后前端把请求加上签名就行。

[duke807]

@weekidjoker #49 你要是觉得 wasm 也可以反编译，那几乎所有商业软件都没有存在的必要了，因为都可以反编译

[liuidetmks]

增加成本，现在前端混淆很复杂的
另外如果使用了 RSA ECC 公钥体系的算法， 公钥只能加密的算法，你是无法解密的。只能服务器解密