表单提交数据是否安全？前端JS编码SHA1能否防止数据被拦截？

嘿，这个问题问到点子上了，咱们分两部分来聊清楚：

一、表单提交时的数据泄露风险 #

首先得明确：如果你的网站用的是HTTP协议，不管后端有没有用SHA1编码存储，传输过程中的原始数据（用户名、邮箱、手机号等）都是明文的。这时候别说NSA或者有能力的攻击者，哪怕是普通的中间人攻击，都能轻松截获这些原始数据——因为HTTP在网络上传输的是未加密的文本，相当于你的数据在网络上“裸奔”。

但如果换成HTTPS协议，情况就完全不一样了：HTTPS通过TLS协议对整个传输链路进行加密，攻击者截到的只是无法直接解密的密文，根本拿不到原始数据。这才是解决传输层安全问题的核心方案，比任何前端/后端的编码处理都更基础、更有效。

二、前端JavaScript编码方案是否可行？ #

技术上是可行的，但有几个关键坑必须注意，不然反而可能引入新的风险：

• 前端编码逻辑是公开的：JS代码会被浏览器下载并解析，攻击者很容易拿到你的SHA1实现逻辑。如果只是单纯把原始数据用SHA1编码后提交，攻击者可以用彩虹表快速反查出原始数据（尤其是手机号、常见用户名这种数据，彩虹表覆盖率极高）。
• 无法替代HTTPS：就算前端做了编码，如果你还是用HTTP传输，编码后的哈希值照样会被拦截。攻击者甚至可以直接用这个哈希值模拟请求（比如登录场景下，如果后端只对比哈希值的话），一样能绕过验证。
• 不能替代后端的安全处理：前端的编码是不可信的——攻击者可以轻易绕过JS代码，直接提交篡改后的数据到后端。所以哪怕前端做了编码，后端必须再对收到的数据进行加盐哈希处理（而且别用SHA1了，现在推荐bcrypt、Argon2或者PBKDF2这类抗暴力破解的慢哈希算法），这样才能真正保障存储层面的安全。

总结一下 #

1. 优先搞定HTTPS，这是解决传输数据泄露风险的根本，没有HTTPS，其他编码手段都是治标不治本；
2. 前端JS编码可以作为额外的安全层，但不能替代HTTPS和后端的加盐哈希；
3. 赶紧把SHA1换成更安全的哈希算法，SHA1已经被证实存在碰撞漏洞，抗攻击能力不足。

内容的提问来源于stack exchange，提问作者Stefan