HTML本身不提供组件级加密能力，所谓“组件级别数据加密”实为用JavaScript在DOM元素渲染或提交前对其敏感值加密，必须配合HTTPS；推荐使用crypto.subtle.encrypt()配合AES-GCM（每次随机IV）和RSA-OAEP密钥协商，禁用base64或MD5等伪加密手段，且应优先通过权限校验动态加载敏感内容而非前端加密。
HTML 本身不提供组件级加密能力，所谓“组件级别数据加密”实际是指：在 DOM 元素（如 <input>、<div data-secret>）所承载的敏感数据被渲染或提交前，用 JavaScript 对其值做加密处理。这必须配合 HTTPS 传输，否则毫无意义。
crypto.subtle.encrypt() 在表单字段中怎么用
现代浏览器支持 Web Crypto API，可用于对单个字段值加密，比如密码或身份证号输入框内容。关键不是“给 HTML 加密”，而是拦截用户输入、加密后再提交。
- 必须在 HTTPS 页面中调用，
crypto.subtle在 HTTP 下直接报错 - 不能对
type="password"的<input>直接加密——它只是 UI 遮掩，真实值仍为明文字符串，需读取.value后手动加密 - AES-GCM 是首选：它同时加密+认证，避免篡改；IV 必须每次随机生成（
crypto.getRandomValues(new Uint8Array(12))），且随密文一起传给后端 - 密钥不能硬编码在 JS 里，推荐由服务端下发公钥，前端用
RSA-OAEP加密临时会话密钥，再用该密钥执行 AES 加密
示例片段（仅示意流程）：
const encoder = new TextEncoder();
const iv = crypto.getRandomValues(new Uint8Array(12));
const data = encoder.encode(document.getElementById('id-card').value);
// 假设 key 已通过 RSA-OAEP 安全协商获得
const ciphertext = await crypto.subtle.encrypt(
{ name: "AES-GCM", iv },
key,
data
);
// 提交时把 ciphertext、iv、algorithm 一并发过去
fetch('/api/submit', {
method: 'POST',
body: JSON.stringify({
encrypted: Array.from(new Uint8Array(ciphertext)),
iv: Array.from(iv),
algo: "AES-GCM"
})
});
为什么不要用 base64 或 md5 替代加密
base64 不是加密，是编码；md5 和 sha1 是哈希，不可逆，且已被证实不安全。它们常被误用于“隐藏”密码，但实际等于明文暴露。
立即学习“前端免费学习笔记（深入）”；
-
btoa("123456")→"MTIzNDU2"，任何人在控制台敲atob("MTIzNDU2")就还原 -
md5("123456")→"e10adc3949ba59abbe56e057f20f883e"，查彩虹表秒破 - 若后端直接存
md5值当密码，等于放弃所有安全防线；正确做法是前端不处理哈希，由后端用bcrypt或scrypt处理 - 真正需要加密的场景（如传输银行卡号），必须用
AES-GCM或RSA-OAEP，且密钥生命周期要可控
动态加载 + 权限校验比前端加密更有效
与其费力加密某个 <div> 里的文本，不如让这个 <div> 根本不出现，直到后端确认权限。
- 初始 HTML 只保留空容器：
<div id="sensitive-content"></div> - 页面加载后，用
fetch请求/api/user/profile，携带Authorization: Bearer xxx - 后端校验 token 有效性、作用域（scope）、甚至设备指纹，再决定是否返回加密后的字段（或直接解密后返回明文）
- 这样敏感数据从未以可读形式存在于前端内存，规避了 XSS 读取、调试器抓取、快照泄露等风险
注意：接口必须走 HTTPS，且响应头应设 Content-Security-Policy 防止注入，Cache-Control: no-store 防止缓存。
最容易被忽略的是密钥生命周期和错误处理——比如 IV 复用导致 AES-GCM 破解、加密失败时仍提交明文、或者把私钥塞进 <script> 标签里。真正的组件级防护，不在 HTML 结构，而在数据流每个环节的收敛与校验。
