去年某电商平台被曝出用户登录请求以明文方式在公网传输，明文抓包工具一开，传输账号密码直接躺在HTTP报文里。漏洞这不是修复孤例。很多团队在内部系统、明文老旧API、传输甚至某些移动端接口上，漏洞仍然让敏感数据裸奔。修复明文传输不是明文“配置疏忽”，它本质上是传输设计阶段就没把威胁模型当回事。

先说清楚一个常见误解：用了HTTPS就万事大吉？漏洞不一定。如果TLS配置允许降级、修复证书校验被客户端忽略、明文或者混合内容加载，传输明文照样漏。漏洞我见过一个后台管理系统，登录页是HTTPS，但登录请求发往一个HTTP接口——开发者把前端页面和API域名搞混了。浏览器控制台一片红色警告，没人看。

修复这件事，得从三个层面动手。

传输层是底线。全站强制HTTPS，HSTS头加上，max-age至少设六个月。别用自签证书糊弄内部系统，内部中间人攻击一样能截获。有个做金融的朋友告诉我，他们内网API曾经用HTTP，理由是“在内网”。结果办公网被钓鱼，攻击者横向移动后直接嗅探到核心交易指令。内网不等于可信网络，这个观念得改。

应用层要补刀。密码字段在提交前做一次非对称加密，比如用服务端公钥加密后再传输。这招不能替代HTTPS，但能防住TLS终止后的明文泄露——比如负载均衡器到后端服务器那一段。很多云环境里，SLB到ECS之间是HTTP，运维觉得“反正在机房内”。机房内被嗅探的案例不少。

再就是协议选择。别用FTP、Telnet、HTTP这些明文协议传敏感数据。SFTP、SSH、HTTPS是基本要求。有个做物联网的团队，设备上报数据用MQTT over TCP，没上TLS。结果某次固件更新被中间人篡改，几千台设备变砖。后来他们改成MQTT over TLS，端口从1883换到8883，成本几乎为零。

代码层面也有坑。日志里打印完整请求体、异常堆栈里带出密码、调试接口没关——这些都会让明文数据落到磁盘或监控系统里。我审查过一个Spring Boot项目，logback配置把org.springframework.web的日志级别设成DEBUG，登录请求的body全打出来了。修复方式很简单：日志脱敏，或者干脆别打敏感字段。

移动端更麻烦。Android的network_security_config没配好，允许明文流量；iOS的ATS默认开启，但有人为了兼容老接口手动关掉。关掉之后，所有请求都可能走HTTP。建议的做法是：在CI流程里加一条检查，扫描代码中是否出现http://开头的API地址，出现就构建失败。粗暴但有效。

最后说个真实案例。某政务系统被等保测评扣分，原因是“敏感信息传输未加密”。开发团队一开始想用前端JS加密库糊弄过去，后来发现测评方直接抓包看TLS版本。老老实实上了TLS 1.2+，禁用弱密码套件，把RC4和3DES都踢掉。整改花了两天，但之前裸奔了三年。

明文传输漏洞的修复不复杂，复杂的是承认它存在。很多团队觉得“没人会抓我们的包”，直到有人真的抓了。别等出事再改，现在就去检查你的登录接口、支付回调、API网关——看看有没有哪个请求还在用http://开头。