为安全问题，早上公司热烈讨论

我们公司在北京，这边安全方面查得很严，监管部门会直接要求任何个人敏感信息都要求必须二次加密，确保真正需要解密的地方才解密（也就是说你的负载均衡、反向代理、网关之类的也不应该进行解密），具体哪些算个人敏感信息可以参考国家标准 GB/T 35273-2020 的附录 B 。

二次加密这个用个非对称加密方案就可以了，前端放个公钥，后端用私钥解密，公钥随便公开，只要确保加密后的密文不被轻易抓包解密就可以了。

你们的问题归根结底其实是职责划分不清，导致前后端在这个灰色地带丧失决策能力。现在凡是一定规模的企业都至少需要个专职的安全团队来负责提供安全方案，你们现在没有的话，估计将来监管落到你们所在的地区也会要求你们有一个，很多合规工作靠前后端技术人员兼任是做不过来的，而且专门的安全团队必须给你们做安全培训和考核（监管部门会查培训和考核记录的），帮你们树立起安全意识。

让他抓个包看一下就行了，https 本来就是通道加密

@amon
我不知道是我没表述清楚还是什么，我没说测试发现这个问题有问题，安全这是一个大问题，但是这是一个 bug ，难道我要来个 base64 糊弄一下么，这是需要完整方案的东西和规范的，要不要加密？怎么加密？加密到什么程度？

所以我跟她的态度就是这个不是 bug ，是个大东西，这次我修复不了，她不肯，一定要我这次加，我说你一定要我加，去找前后端 leader 给我方案，安全相关的东西我负责不了，经验不够

然后前后端 leader 开始吵了，后端 leader 的观点是，前端不需要，https 保证了大部分安全的场景，后端方面加密数据给前端就行了，而且我们一没规范，二人员少（开发团队前端+测试+后端+2leader 总共 7 个人），要搞这方面的东西话投入太多，取舍的话就是没必要

前端 leader 也在那吵，说要，一定要，但是拉着后端老大吵了半小时什么技术方案不给，说来说去就是 https 就不安全么巴拉巴拉，我能怎么怎么破解，最后后端老大不想理前端老大，然后前端老大跑到我们前端面前说我们前端没安全意识，我就烦了，他自己一直没出什么安全方案规范，甚至公司的项目混淆没混淆都不知道，最后丢到我们干活的头上，我就回了

1. 你们没有产品经理吗，这个让他定就好了啊。

2. 你的工作方法不对，能团队内部搞定的事情，就不要让这么多人掺和。
你看看这种方式是不是更合理：
a. 测试提不要明文（身份证、电话、银行卡这种固定格式明文一眼就看出来是什么数据。你用 base64 加一些混淆编码，肉眼是识别不出来的。）
b. OP：这样的改动要增加工期，你咨询过产品了吗，他要不要？；
c. 产品或者测试说要；
d. 跟自己的领导沟通，这个需求用啥“加密”，base64 行不行，让他知道这个事情，大概率他会说你自己定；
e. 反馈给测试和产品，有加密了；
f. 他们认可那就结束了，改动又不大；他们不认可，再让前后的 leader 进来定加密方案。

你的沟通方式，让后端和测试对你都有印象都差（推三阻四，不好沟通），最严重的是让你领导对你大减分。

3. 正如上文所说，身份证、电话、银行卡这种固定格式明文一眼就看出来是什么数据的，尽量不明文，应该有这样的意识。

加密流程只要保存好密钥就行,比如前端公钥加密,后端私钥解密.代码公开也无法解密.

@zjuster
我没说清楚，看 143 楼回复

安全不绝对等于绝对不安全？

就随便加个密，AES 甚至 base64 都好，哪怕中间人理论上可以破解，安全性的提升也是实打实的，

产品最终是要交给金融、政企行业去用的话， 是不允许敏感信息 [明文] 的。https （ tls ）实现传输的安全。

请求过程随着项目迭代，后续可能经过很多层，前端的请求拦截， 后台 tls 代理的透传后都可以获取明文，增加了风险。

另外，你还可以建议测试人员测试后台日志输出，敏感信息要脱敏打印。

@zjuster 不要明文应该是需求，不应该测试提，base64 也需要后端支持的，否则后端获取 base64 数据没解码肯定没法用，所以这个问题不管怎么样都不是只有前端能解决的问题，这个问题抛到 leader 哪里一点问题都没有，为什么叫推三阻四不好沟通呢？

QA 有安全意识不错。 一般来说这应该是 security 应该管的 如果要加密也应该是让 leader 去做

只能说。。做金融产品还是按合规去做吧。。尽职免责

好多测试给自己强行加戏。。。按开发需求测试验收不就完了？ 你可以提建议给产品加需求加排期 但请不要打上 bug 标签！ 有些按 bug 率计算绩效的公司 开发恨不得砍死你测试

http body 加密，中间层的各种 waf 直接瞎了，TM 黑客能笑死

这不叫加密，叫数据编码

我记得前端随机生成 AES 密钥，用 AES 密钥加密明文，再用后端给的 RSA 公钥加密这个 AES 密钥。把两个加密组传给后端解开，不就行了？

我觉得未必有必要做，想获取你数据的，能绕过 TLS ，改你网页很难么。。直接注入一段代码抄一份数据转发出去不就完了。。。还不如搞 mTLS ，谁也别信谁。
另外楼上有办法直接在线把对称或非对称的密钥传给用户的，中间人换一下不就能愉快解密了？

[什么是 mTLS ？| 双向 TLS | Cloudflare]( https://www.cloudflare.com/zh-cn/learning/access-management/what-is-mutual-tls/)

安全这东西，多套一层一般来说是多一分安全。不过希望浪费计算机资源也能像浪费粮食一样被众人认识。。。。。。。

弱密码比没有密码更糟糕，无效的加密比不做任何处理更糟糕

@lakehylia #155 这不就是 https 么。。。

所以重点是类型不应该是 bug ，而是 feature （好让老板加鸡腿）？那把这个和 leader 们说清楚呗。。让他们去吵做不做这个事，应该不是重点吧。。

@blackshow 套娃也是可以的嘛，这样只要你的密钥服务器没有被攻破，任何中间人是拿不到明文的。可控。