3. 接口协议基础：HTTP/HTTPS、REST、gRPC、WebSocket、消息队列
说到接口协议，很多做安全的同学容易陷入一个误区——认为只要把数据加密了，脱敏这事儿就算完了。其实不然。
我在实际项目里踩过最大的坑，就是没搞懂协议本身对数据分布的影响。你想想看，不同的协议，数据在传输链路上的“暴露点”完全不一样。脱敏方案要是跟协议特性拧着来，轻则性能崩盘，重则数据照样裸奔。
3.1 你真的了解 HTTP 和 HTTPS 吗？
HTTP 是文本协议，说白了数据在网络上走的时候，是明文的。我个人习惯把 HTTP 请求拆成三部分看：请求行/状态行、消息头、消息体。
- 请求行：包含 URL 和参数。敏感数据经常出现在 URL 查询参数里，比如
?userId=12345。这是脱敏的第一道关卡。 - 消息头：Cookie、、Authorization 都在这儿。我不会在响应头里暴露内部用户 ID，曾经有个项目就是因为这个被扫出了漏洞。
- 消息体：JSON/XML 正文。这是脱敏的主战场，特别是 POST/PUT 请求的 body。
HTTPS 是在 HTTP 基础上套了一层 TLS。很多人以为 HTTPS 就万事大吉了，其实不是。加密只在传输过程中有效，数据到了服务端内存，还是明文的。我遇到过一种情况：日志系统直接把解密后的请求体全量打印，结果脱敏方案白做了。
⚠ 注意：HTTPS 不解决日志泄露问题。如果你在网关层做脱敏，务必在明文到达应用之前完成替换，否则日志里依然会留下敏感痕迹。
3.2 RESTful 风格：无状态是好事也是坏事
REST 是 HTTP 的一种设计风格。它的核心是无状态——每个请求都包含完整信息，服务端不保存会话上下文。
为什么要强调这个？因为无状态意味着同一个用户的敏感信息会在每次请求中重复出现。我接手过一个项目，他们的 REST API 把用户身份证号放在每个请求的路径参数里，脱敏逻辑写得再漂亮，日志和监控系统还是会抓到完整数据。
| REST 元素 | 常见敏感点 | 我建议的脱敏时机 |
|---|---|---|
| URI 路径参数 | 用户ID、订单号 | 网关层入站时脱敏 |
| 查询字符串 | 手机号、邮箱 | 日志输出前替换 |
| 请求/响应 Body | 身份证、银行卡 | 序列化前/反序列化后 |
| HTTP Header | 、会话ID | 不可脱敏，但需脱敏日志 |
REST 还有个特点：资源通过 URL 标识。你想想看，如果用户查询自己的订单，URL 是 /orders/12345，这个“12345”是不是敏感信息？在我的实践中，至少要把内部 ID 映射成 UUID 或者加盐哈希再暴露出去。
3.3 gRPC：二进制协议的脱敏难点
gRPC 跟 REST 完全不同。它基于 HTTP/2，使用 Protobuf 序列化，数据是二进制的。这给脱敏带来了新挑战。
我记得第一次对接 gRPC 服务时，想用传统的方式——拦截 HTTP 请求体做字符串替换。结果发现根本行不通，因为 Protobuf 是结构化二进制流，不是可读字符串。
💡 核心思路：gRPC 的脱敏必须走 Protobuf 反射或者拦截器。
- 拦截器方案：在服务端拦截器里拿到反序列化后的 Protobuf 对象，再对敏感字段做替换。性能开销可控。
- 反射方案：适用于无法修改代码的情况。通过动态解析
.proto文件和字段标签，自动识别敏感字段并脱敏。但性能会差一些。
另外，gRPC 的流式传输（Streaming）也值得注意。我曾经遇到过一个场景：客户端通过 Server Streaming 持续接收用户数据流，每个消息块都包含了手机号。如果等到消息全部接收完毕再脱敏，内存早就爆了。解决方案是在拦截器里逐条处理。
// gRPC 服务端拦截器示例（简化）
func UnaryServerInterceptor() grpc.UnaryServerInterceptor {
return func(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
// 在 handler 之前，对 req 做脱敏
switch r := req.(type) {
case *pb.UserRequest:
r.Phone = desensitizePhone(r.Phone) // 脱敏手机号
}
return handler(ctx, req)
}
}3.4 WebSocket：长连接下的持续脱敏
WebSocket 是长连接，协议一旦建立，数据帧就会持续双向流动。脱敏在这里的难点不是“一次”，而是“持续”。
我在做实时消息平台时，遇到过一个问题：用户通过 WebSocket 推送敏感数据，如果只在建立连接时做一次脱敏，后续的消息体里依然会有明文。更头疼的是，WebSocket 的消息没有标准的“请求-响应”结构，不同帧之间没有明确的分界。
解决方案其实不复杂：
- 帧级别脱敏：在消息发送队列之前，对每个帧的 payload 做正则匹配或结构解析。我个人倾向于用结构解析，因为正则容易漏匹配。
- 连接级别上下文：建立 WebSocket 连接时，缓存用户的脱敏策略（比如手机号显示前3后4），后续所有消息都复用这个上下文。
🔧 实战技巧：WebSocket 的脱敏最好放在协议网关层。因为业务服务通常不关心脱敏细节，网关做完一次就好了。我曾经把脱敏逻辑写进了业务代码里，后来每个新功能都要重新配脱敏规则，维护成本极高。
3.5 消息队列：异步解耦后的脱敏盲区
消息队列（Kafka、RabbitMQ、RocketMQ）很容易被安全团队忽略。为什么？因为很多人的思路是：“消息队列是内部传输的，不对外暴露，所以不用脱敏。” 这个想法非常危险。
我亲眼见过一个案例：业务系统通过 Kafka 把订单信息同步到大数据平台，订单里包含了用户身份证号。所有人都觉得消息队列在内部网络，很安全。结果某个下游服务的日志系统出了问题，把 Kafka 消息体全部打到了 ELK 里，最后 ELK 被拖库了。
消息队列的脱敏，我认为要分两个层面：
| 层面 | 说明 | 我的做法 |
|---|---|---|
| 生产者侧 | 发送消息前脱敏 | 在序列化之后、发送之前，用拦截器替换敏感字段 |
| 消费者侧 | 接收消息后二次脱敏 | 防止生产者忘记脱敏或规则不一致 |
这里有个坑：如果生产者和消费者都做脱敏，容易造成“双重脱敏”——比如手机号被脱敏成 138****1234，消费者拿到后又脱敏一次，变成了 138********。我采用的方案是“生产者做主脱敏，消费者只做校验和兜底”。
3.6 一张图看懂协议与数据分布
下面这张图，是我给团队培训时常用的。它直观地展示了不同协议下，数据在传输过程中的“暴露位置”。理解了这张图，你就知道脱敏应该在哪个环节切入。
3.7 我的选择建议
讲了这么多，你可能会问：那我应该用哪种协议？脱敏方案怎么选？
我个人的经验是这样的：
- 如果是对外开放的 API，优先选 REST + HTTPS。脱敏在网关层统一处理，技术成熟，工具多。
- 内部服务间调用，考虑 gRPC。性能好，但必须强制每个服务都用拦截器做脱敏，不能有例外。
- 需要实时推送的场景，用 WebSocket。但一定要在网关层做帧级别的脱敏过滤，别把压力给到业务服务。
- 异步解耦，消息队列是王道。记住一句话：消息队列里的数据，默认就是对外泄露的，必须提前脱敏。
好了，关于接口协议的基础就聊到这儿。你想想看，你的项目里，数据在哪个环节最容易泄露？搞清楚这个问题，脱敏方案就成功了一半。