HTML加密配合数据脱敏技巧

先明确一个核心观点：我们常说的“HTML加密”其实是个伪命题。HTML本身不具备加密能力，它只是标记语言。真正的安全防线，必须前移到服务端。数据脱敏的逻辑，应该在数据离开数据库之前就完成。前端所做的渲染、混淆、掩码，都只是在这个安全前提下的补充操作，绝不能替代服务端这个“可信源头”的输出控制。

说到底，安全的核心原则是：不信任任何来自客户端的信息，包括它声称的角色和权限。所有的敏感数据展示，都必须基于服务端已经处理好的、符合当前用户权限的“安全视图”。

服务端脱敏必须先于任何前端处理

想象一个典型的错误场景：前端用Ja vaScript的replace()函数给手机号打码，但服务端接口返回的却是完整的{“phone”: “13812345678”}。这无异于在裸奔。用户只要打开浏览器的开发者工具，在Network面板里一眼就能看到原始数据。这些数据还可能被缓存到localStorage，或通过innerHTML注入，甚至在控制台里被直接读取。

所以，脱敏的起点必须是服务端。具体怎么做？有几个成熟的思路：

• 在后端模板或序列化层直接处理：比如在Spring Boot中，可以使用@JsonSerialize(using = PhoneMaskSerializer.class)这样的注解，确保从接口返回时，手机号字段就已经是“138****1234”这样的格式。
• 在数据库查询时进行脱敏：直接在SQL语句里完成。例如MySQL可以使用CONCAT(LEFT(phone,3), '****', RIGHT(phone,4))。如果使用MyBatis，也可以在XML映射文件中通过标签进行预处理。
• 基于角色的动态脱敏必须由服务端裁决：不同角色的用户看到的数据精度不同，这个判断权必须牢牢握在服务端手里。根据用户的role或权限上下文，决定是否调用maskPhone()函数。前端绝不能做类似if (user.role === 'intern') { mask() }的判断，因为前端的角色信息是可以被篡改的。

前端掩码不是加密，但必须在 DOM 插入前完成

当前端拿到服务端返回的、已经脱敏或部分脱敏的数据后，可能还需要进行最后的展示层格式化。比如，用一句正则phone.replace(/(\d{3})\d{4}(\d{4})/, “$1****$2”)来格式化手机号。

请注意，这仅仅是“掩码”，不是加密。而且它的执行时机至关重要：必须在数据被插入DOM之前完成。无论是直接操作innerHTML，还是在React/Vue的渲染函数中处理，都要确保数据在变成DOM节点的那一刻，就已经是掩码后的状态。绝对不能先渲染明文，再通过querySelectorAll(“td.phone”)去遍历修改，那样会导致页面短暂地闪现明文，用户体验和安全观感都很差。

这里还有一些细节需要注意：

• 处理中文、日文等多字节字符的姓名时，要慎用substring(0,3)，它可能按字节截断导致乱码。更推荐使用.slice(0,3)或能识别Unicode字符的正则表达式，如/^[\u4e00-\u9fa5a-zA-Z0-9]{1,3}/。
• 对于表格中频繁出现的敏感字段（如身份证号、邮箱），应该在前端也抽象出统一的处理服务（Service层），避免在每个组件里重复编写掩码逻辑，难以维护且易出错。
• 一个常见的坑是：表单中展示的是掩码后的数据，但提交时却错误地提交了这个掩码字符串。务必确保提交给后端的是存储在隐藏域或内存变量中的原始值（通常由服务端在另一个字段或接口提供），而不是前端展示用的星号字符串。

Web Crypto API 动态解密只适合极少数可信场景

听起来很高级：用window.crypto.subtle.decrypt()在前端解密敏感内容。但这套方案的落地门槛极高，只适用于非常特定的内部场景。

首先，整个流程必须运行在HTTPS下。其次，密钥绝不能硬编码在前端代码里，否则等同于明文。初始化向量（IV）也必须每次随机生成（例如使用crypto.getRandomValues(new Uint8Array(12))）。一旦密钥或IV泄露，加密就形同虚设。

因此，它仅建议用于内部管理系统中，那种“点击查看详情”按钮后才按需加载极端敏感信息的场景。并且，解密后必须遵循严格的安全守则：

• 解密结果不能写入DOM属性、dataset或全局变量，防止被其他脚本窃取。
• 最好将解密内容暂存在闭包或临时的Map对象中，操作完成后立即删除引用，避免其在内存中长期驻留。
• 绝对禁止在调试中使用console.log()打印解密结果。在表单中展示时，避免直接赋值给input.value，可以考虑使用临时的contenteditable区域或完全受控的组件来显示。

Base64 / btoa / atob 不是加密，是自欺欺人

这是一个需要彻底破除的迷思。把btoa(“13812345678”)得到的MTM4MTIzNDU2Nzg=字符串放在前端，并认为它被“加密”了，这是一种危险的自欺欺人。

Base64只是一种编码方式，目的是为了用文本安全地表示二进制数据，它没有密钥，也没有任何加密算法强度。任何用户都可以在控制台里，用一行atob(“MTM4MTIzNDU2Nzg=”)轻松还原出原文。常见于把这种“密文”塞进data-encrypted自定义属性，旁边还配上“已加密”的注释，这本质上只是给开发者自己的一种心理安慰。

必须认清：

• btoa()和atob()是编码/解码，与加密无关。
• 任何写入HTML注释、data-*属性、或textContent的所谓“密文”，在安全层面都等同于明文暴露。
• 如果确实需要在前端进行信息混淆（注意，不是加密），至少应该使用Web Crypto API的AES-GCM等真正加密算法，并且确保密钥由服务端动态下发、单次有效。

最后，需要时刻警惕一个最容易被忽略的要点：数据脱敏，绝不仅仅是在字符串里加几个星号那么简单。它是一个系统工程，起点是数据源头的访问控制。服务端根据接口契约和用户的权限模型，决定“要不要吐出某个字段”以及“吐出到什么精度”。前端的所有操作，都只是对这个安全契约的忠实、无误的执行者，它的角色是渲染，而不是补漏或兜底。把安全的希望寄托于前端，从一开始就错了。