传输安全不能只靠加密，完整性校验才是防止数据在传输过程中被篡改的关键防线，两者缺一不可。加密解决的是“看不懂”的问题，完整性校验解决的是“被改过”的问题，一个成熟的传输安全方案，必须同时具备机密性、完整性和可用性，这是业内公认的“CIA三要素”。
为什么加密之后，数据还是不安全
很多人有个误区：以为上了HTTPS，数据就万事大吉，这个想法很危险，加密确实能防止中间人直接读取内容，但它防不住一种更隐蔽的攻击篡改。
想象你给朋友寄了一个带锁的箱子，钥匙只有你们俩有，快递途中，有人往箱子里塞了一张假纸条，箱子没被打开，锁也完好无损，但里面的内容已经变了，你的朋友收到后，用钥匙打开箱子，看到的是一张被掉包的字条，他不知道这字条不是你写的,因为锁没有被破坏的痕迹。
HTTPS加密就是这个带锁的箱子，SSL/TLS协议负责加密传输内容，防止被窃听，但如果攻击者截获了密文，虽然解不开，却可以修改密文中的某些位，或者重新拼接、重放之前截获的合法数据包，接收方解密后,得到的就是被污染过的数据。
业内专家指出，多数数据泄露事件并非源于加密被破解，而是源于完整性校验缺失，攻击者绕过了加密层,在业务逻辑层面实施了篡改。
加密和完整性校验，职责完全不同
加密算法，比如AES、RSA，解决的是机密性问题，它把明文变成密文，没有密钥的人看不懂，但密文在传输过程中是否被改动,加密本身无法察觉。
完整性校验，通常通过哈希算法或消息认证码来实现，解决的是数据一致性问题，它给数据生成一个“指纹”，接收方拿到数据后重新计算指纹,一对比就能发现数据有没有被动过手脚。
用一个表格来对比更直观：
| 防护目标 | 加密（机密性） | 完整性校验（完整性） |
|---|---|---|
| 核心问题 | 数据是否会被偷看 | 数据是否被篡改 |
| 典型技术 | AES、RSA、TLS/SSL | MD5、SHA-256、HMAC |
| 攻击场景
|
窃听、嗅探 | 中间人篡改、重放攻击 |
| 失效后果 | 隐私泄露 | 数据错误、业务欺诈 |
很多开发者在设计接口时，只做了HTTPS加密，却没做签名校验，这就等于给快递箱子上了锁，却没贴封条，数据是安全地传过去了，但内容是不是原封不动,没人知道。
文件传输完整性校验怎么做：从哈希到数字签名
具体到实操层面，完整性校验的实现路径分几个层级，复杂度从低到高,安全性也逐级递增。
第一步：用哈希值做基础校验
最简单的办法，是发送方在传输文件的同时，单独提供一个SHA-256哈希值，接收方下载文件后，用同样的算法计算本地文件的哈希值，两个值一对比,完全一致说明文件未被改动。
这一步在很多开源软件下载页面都能看到，网站会提供安装包和一个哈希值字符串,操作路径很清晰：
- 下载文件后，打开终端或命令行
- 输入
sha256sum 文件名或certutil -hashfile 文件名 SHA256 - 对比输出结果和官网提供的哈希值是否一致
但这个方法有个明显缺陷：如果攻击者同时篡改了文件和哈希值，接收方就无法察觉，哈希值本身没有加密保护，属于被动校验。
第二步：用HMAC实现防篡改
HMAC（哈希消息认证码）在哈希的基础上，加入了共享密钥，发送方用密钥对数据计算HMAC值，接收方用同一个密钥重新计算，攻击者没有密钥，就算篡改了数据,也算不出正确的HMAC值。
这一步在实际开发中非常常用，比如小程序接口、App后端API，通常会在请求头里带上一个sign参数，这个sign就是通过HMAC-SHA256对请求参数加盐（密钥）计算出来的，后端收到请求后，用同样的密钥和算法重新计算签名,不一致就直接拒绝请求。
第三步：用数字签名实现不可抵赖
HMAC的密钥是双方共享的，如果密钥从某一方泄露，安全性就崩塌了，更高级的方案是数字签名，基于非对称加密，发送方用私钥签名，接收方用公钥验签，私钥只有发送方持有，所以签名无法伪造,也无法抵赖。
这一步在金融、政务等高安全场景中是标配，比如银行间报文传输，通常采用数字证书加XML签名的方式，确保每一笔交易报文都来自真实的发送方,且内容未被改动。
https加密为什么还不够：真实业务中的篡改场景
在日常的Web开发中，很多人觉得“我上了HTTPS就安全了”,这个认知偏差在接口设计和文件传输场景中尤为明显。
以网站前端页面为例，现在很多网站通过CDN加速，静态资源放在CDN节点上，如果CDN节点被劫持或配置出错，返回的JavaScript文件可能被植入恶意代码，HTTPS能保证CDN到用户这段链路是加密的，但无法保证CDN节点上存储的文件是原始版本。子资源完整性（SRI）机制就派上了用场，前端在引入外部脚本时，可以在<script>标签里加上integrity属性，浏览器加载脚本后会自动计算哈希值，和属性里声明的值对比,不一致就拒绝执行。
再举一个实际场景：物联网设备固件升级，设备通过网络下载固件包，如果只做HTTPS加密，固件包在传输途中被篡改，设备刷入后可能直接变砖，甚至被植入后门，正规的固件升级流程，必须对固件包做数字签名，设备在升级前先验签,签名合法才允许刷入。
传输完整性校验的工具链也很成熟，常用的开源工具包括OpenSSL命令行工具、hashlib库（Python）、crypto模块（Node.js），以OpenSSL为例,对文件做数字签名和验证的操作路径如下：
- 生成密钥对：
openssl genrsa -out private.pem 2048 - 提取公钥：
openssl rsa -in private.pem -pubout -out public.pem - 对文件签名：
openssl dgst -sha256 -sign private.pem -out file.sig file.zip - 验证签名：
openssl dgst -sha256 -verify public.pem -signature file.sig file.zip
这套命令在Linux服务器上是标配，Windows也可以通过Git Bash或WSL环境运行。
数据完整性校验在Web应用中的关键性
对于业务系统来说，完整性校验的意义不只是防篡改，还关乎业务数据的可信度。
比如电商平台的支付回调接口，用户支付成功后，支付平台会向商户服务器发送异步通知，如果商户服务器只验证了来源IP或简单参数，攻击者完全可以伪造回调，把订单状态改成“已支付”，正确的做法是，支付平台用私钥对回调参数签名，商户服务器用支付平台公钥验签，验签通过，才能确认这笔通知确实来自支付平台，且金额、订单号没有被改动。
再比如API接口的防重放攻击，攻击者截获一个合法请求后，在有效期内重复发送，如果接口只做加密，不做时间戳和随机数的完整性校验，攻击者可以反复提交同一个请求，造成重复下单或重复扣款，加入timestamp和nonce参数，并对这些参数做签名，服务端就能识别出超时请求或重复请求,直接拒绝。
行业共识认为，传输安全的最佳实践是“加密+签名+时间戳”三件套，加密防窥探，签名防篡改，时间戳防重放，任何一个环节缺失,整个安全链路都存在短板。
Q&A：关于传输安全与完整性校验的高频问题
传输安全除了加密还要做完整性校验，具体怎么做？
传输层加密由TLS/SSL协议负责，完整性校验需要在应用层实现，最常用的方案是HMAC-SHA256，发送方和接收方共享一个密钥，对请求体计算MAC值，放入请求头或消息体中，接收方收到后重新计算并比对，如果做文件分发，建议使用数字签名，发送方用私钥签名，接收方用公钥验签，这样即使接收方数量众多，也不需要在每个接收方保存相同的密钥,安全性更高。
完整性校验用MD5算法可以吗？
不建议，MD5算法已被证实存在碰撞攻击，攻击者可以构造两个内容不同但MD5值完全相同的文件，让校验形同虚设，目前行业最低要求是SHA-256，安全敏感场景建议使用SHA-256或更高级别的哈希算法，配合HMAC或数字签名使用，如果业务系统还在用MD5做完整性校验，建议尽快升级,这是当前安全审计中的常见高风险项。
完整性校验失败应该怎么处理？
处理原则是直接拒绝，不降级，文件下载场景，如果哈希值不匹配，立即删除下载文件，提示用户重新下载或更换下载源，接口调用场景，如果签名验证失败，返回错误码并记录日志，不要尝试“修复”数据后继续处理，日志中应记录请求来源IP、请求时间、签名值、服务端重新计算的值等关键信息，方便事后追踪溯源，对于连续多次校验失败的来源,应考虑加入黑名单或触发告警策略。