结论先行：前端掩码只是展示层，不是脱敏。手机号显示成 138＊＊＊＊1234，只要接口里仍返回全量，抓一次包就拿到明文。真正的脱敏按传输、存储、展示、导出、日志五层分开做：传输加密、存储加密或令牌化、展示按角色掩码、导出走审批与规则、日志禁止打印明文。

一、五层拆解，前端只占其中一层

把“脱敏”当成一个页面效果，是这件事失败的起点。按数据流动的顺序分层，每层都有独立的责任人和验收方法。

这五层里，前端能控制的只有展示层的排版。但凡有人在需求评审时说“前端已经打码了”，就要立刻追问一句：接口返回的是什么。

数据安全的分层防护思路，在低代码平台的数据安全如何保障里有更完整的六层框架，本文的五层可以看作它在字段粒度上的展开。

二、常见字段的掩码规则

掩码规则要写成制度，而不是让每个开发随手写正则。下面这份表覆盖高频字段，可按行业调整位数。

两条原则：星号数量固定，不随真实内容变化，否则长度本身就成了信息；掩码由服务端做，前端不参与字符替换。

三、真实值不下发：掩码值 + 全量查看接口

最可靠的做法是让明文永远不出服务端。列表与详情接口统一返回掩码值，需要看全量的场景走单独接口，这个接口带四道闸。

1. 独立路由：与普通查询分开，便于单独限流、单独审计、单独关停。
2. 显式授权：校验角色是否在“可查看全量”名单内，按字段逐个判断，不做整表放行。
3. 二次确认或审批：高敏字段（身份证、银行卡）要求填理由，或走审批后短时有效。
4. 强制审计：记录查看人、对象、字段、时间、来源 IP、理由，日志本身不可被业务账号修改。

实现时有个细节容易错：掩码值与真实值必须有稳定的对应关系，否则用户点“查看全量”时无法定位到记录。正确做法是记录主键照常返回，掩码只作用于字段值，不要连 ID 一起混淆。

另一个细节是缓存。掩码结果可以缓存，全量结果不要进共享缓存，否则一个用户的授权会污染另一个用户的响应。

四、导出、测试数据与日志

导出是脱敏最常见的破口。导出任务应当在服务端生成文件，并按导出人的权限套用同一套掩码规则；确需原值导出的，走审批、限定行数、加水印与下载有效期。文件生成后放到临时目录，设置自动清理。

测试数据同样要脱敏。很多事故来自测试环境：开发把生产库整库拷到测试环境，所有人都能看到明文。可行做法是按规则生成仿真数据，保留格式与分布、替换真实值；必须用真实数据的场景，先做不可逆替换并登记。

日志是第三个破口。框架的访问日志、异常堆栈、SQL 打印都可能带出敏感字段。要做的是在日志组件里加统一过滤器，对手机号、身份证、银行卡、密码、token 做正则替换，并在代码评审里把“打印入参”列为必查项。审计日志的设计规范可参考站内《操作审计日志设计》一文。

五、上线前自查清单

下面九条逐项打勾，任何一条为否都不建议上线。

1. 列表、详情、关联查询、批量接口，全部返回掩码值，抽查抓包无明文。
2. 全量查看接口有独立路由、角色白名单、理由填写与审计记录。
3. 导出文件按导出人权限生成，敏感字段默认掩码，原值导出有审批。
4. 打印、分享链接、消息通知、邮件模板不带明文。
5. 数据库敏感字段已加密或令牌化，密钥不在代码仓库里。
6. 测试环境数据已脱敏，不含生产明文。
7. 日志过滤器覆盖手机号、身份证、银行卡、密码、token。
8. 掩码规则集中配置，新增字段不需要改多处代码。
9. 审计日志可被独立查询，业务管理员无删除权限。

补充一点工程实践：自托管部署时，可以把掩码与全量查看做成统一的数据服务层，页面只消费接口。猫拽低代码（CatPull）是 Apache-2.0 开源的自托管平台，数据接口由服务端统一生成，掩码规则可以收在这一层，避免每个页面各写一套替换逻辑。

FAQs

Q1：前端用 CSS 或者图片遮住，算脱敏吗？

A：不算。DOM 里仍是明文，改样式、看源码、抓接口都能还原。判断标准很简单：断网后从接口响应里能不能读到明文，能读到就没有脱敏。

Q2：掩码后还要不要做字段加密？

A：要，两件事解决不同问题。掩码防的是“看到”，加密防的是“拖库”。数据库被拿走时，掩码毫无作用，加密或令牌化才是最后一道防线。

Q3：客服需要核对完整手机号怎么办？

A：给“核验”而不是“查看”的能力。比如用户报出后四位，系统只返回匹配与否；确需全量的，走单独授权、限时有效、逐次留痕，并定期复核授权名单。

延伸阅读

• 低代码应用安全加固清单：鉴权、防注入与审计
• 低代码开发平台安全吗？数据与合规怎么保障
• 操作审计日志设计：满足内控与等保要求