http body 是否可以整体加密

额，你搜一下 https 就可以了……

你以为 https 是做什么的

加一句哈，加入不采用公钥校验，被中间人攻击了，这个时候我们可以自己对 body 进行加密什么的吗？

目前业界共识是 https 足够安全，而且如果自己另外搞一套加密，极大可能相当于重新发明 https 。对于 https 防不住的情况，可能需要网络以外的手段去辅助，不能依靠 http 本身了。

网易云的接口不就是加密的嘛

可以加密啊，为什么不可以？只不过双方需要协商并实现加解密处理罢了。

可以

如果没猜错, 目的是防止中间人...
我觉得就算用 js 加密了原始数据..关键解密的还是需要 JS 在浏览器运行..
破解了 JS.加密在牛也就那样了....
安全是相对的.. 要么自己改一下浏览器.

加密和你说的无关。
http 一般就 https+报文加签
银行系统的对外通信，一般都是通过包体加签的方式来保障安全的，报文除了入参之外，额外有个签名字段。
https 本身不出问题的话，其实 https 就够了

想要安全就应该采用业界安全的最佳实践，而不是自己突发奇想搞一套，你自己搞的 100%比不上已经经过真实环境验证和实践的

你秘钥怎么发给客户端？

如果要对 HTTP 的传输过程进行加密，用 HTTPS 就可以了。

如果想对接口的数据格式进行加密，防止别人通过工具抓请求，来分析出接口的调用方法，进而伪造请求的话，就要想办法对请求参数和响应数据进行加密。比如楼上提到的网易云接口，同样的我了解到的支付宝的小程序也是可以配置接口加密的，还有一些银行金融应用，等等。

对数据加密一般用对称加密算法，这就要双方使用相同的 key 进行加解密（ HTTPS 也是用的对称加密算法进行数据的加密，非对称加密算法是用来协商对称加密的 key 的），所以怎么保证 key 的安全性是加密的关键。

实际项目中，所有把 key 硬编码到客户端的做法都是不安全的，不管是前端代码还是 native 的客户端代码，只是破解难度的大小而已。

比较靠谱的办法就是参考 HTTPS 的 SSL 握手的过程，使用非对称加密算法协商加密的 key ，然后后续的数据交互中使用这个 key 进行加解密。

好消息前端项目中也是可以使用的，浏览器已经提供了相关的 API 来实现这个过程（ https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto ），GitHub 上也有开源的 library 做了上层的封装（ https://github.com/travist/jsencrypt ）

js 用 wasm

https+额外签名字段就足以。
如果是 web 浏览器的应用，参数加密没啥意义，纯粹自欺欺人。

@yuezk 感谢大佬，同时也感谢所有参与回复的大家，对 https 安全性又多了一些了解！

@MrdotX #16 不是大佬。其实我说的方案也有点问题。就是虽然可以在浏览器中安全的交换加解密的 key ，但是怎么安全的保存这个 key 是最有挑战性的问题。如果是临时生成，这个 key 必然会保存在某个变量里面，但是如果有人使用开发者工具，在加解密的地方加上断点，那你加密返回的数据格式也一览无余，更何况你的前端代码都是直接暴露给别人的。

可以的，楼主是打算自己实现还是用别人的，实在不清楚的话要不了解下 S/MIME 这一套玩意，看看开源客户端是怎么实现的

看你想解决什么问题
1. 防止中间人攻击，数据安全：直接 https
2. 反抓包：客户端加密可行