为什么API需要数据脱敏
《个人信息保护法》明确规定，处理个人信息应遵循「最小必要」原则。API作为数据输出的主要通道，是数据泄露的高风险点。一个开发调试时为了「方便」返回的完整手机号，可能在上线后成为合规灾难。数据脱敏不是可选项，而是合规红线。
需要脱敏的数据类型清单
必须脱敏的数据包括：个人身份信息（姓名、身份证号、护照号）、联系方式（手机号、邮箱、地址）、金融信息（银行卡号、交易金额、账户余额）、认证凭据（密码、Token、密钥）。脱敏程度：对外展示高脱敏（如138****1234），内部管理适中脱敏（如138****），审计查询可还原（加密存储+按权限解密）。
静态脱敏 vs 动态脱敏
静态脱敏——数据从数据库读取后立即脱敏，脱敏后的数据不可还原。适用于导出报表、测试环境数据生成等场景。动态脱敏——数据在查询时不改变原始数据，在输出到API响应时才根据规则脱敏。适用于同一数据对不同角色展示不同脱敏程度。API场景推荐动态脱敏。
基于角色的差异化脱敏
同一数据对不同角色展示不同的脱敏程度：普通用户（查看自己的数据，可展示完整信息）、客服人员（查看客户数据，展示部分脱敏：138****1234）、开发/运维（查看日志和调试数据，完整脱敏：***）、审计人员（经审批后可查看完整信息，操作全程记录）。
脱敏规则设计
常用脱敏规则：手机号——保留前3位+后4位，中间4位替换为****（138****1234）；身份证——保留前6位+后4位，中间用*代替；银行卡——保留后4位，其余用*代替（**** **** **** 1234）；邮箱——用户名部分保留首尾字符，@后保留（a***b@domain.com）；姓名——保留姓氏，名用*代替（张*、张**）。
日志脱敏：极易被忽略的安全死角
很多团队做了API响应脱敏，却忽略了日志中的敏感数据。开发调试时打印的完整请求参数、异常堆栈中的用户数据、监控系统采集的API调用详情——这些都是数据泄露的高风险点。必须对所有日志系统进行脱敏处理，建议在日志框架层面（如Logback/Log4j2）配置统一的脱敏规则。
脱敏方案的性能考量
数据脱敏会增加一定的CPU开销，但通常不超过5%。优化的关键：在序列化时脱敏（而非在业务逻辑中逐个字段处理）、缓存脱敏规则（避免每次请求都解析规则配置）、批量脱敏（列表接口一次性处理所有数据而非逐条处理）。