HTML5不提供内置富文本加密功能，实际是通过服务端签名验签或哈希绑定实现防篡改；需标准化HTML后签名并隐藏于属性或注释中，私钥严禁暴露前端。

HTML5本身不提供内置的富文本加密功能，所谓“HTML5加密富文本防篡改”，实际是指在Web前端+后端协同场景下，对富文本内容（如用户通过contenteditable或编辑器（TinyMCE、Quill、CKEditor等）生成的HTML片段）进行完整性保护与防篡改验证。核心不是“加密显示”，而是“签名验签”或“哈希绑定”，确保内容未被客户端恶意修改。

使用数字签名绑定富文本内容

将富文本HTML字符串经服务端私钥签名，把签名值（如HMAC-SHA256或RSA-SHA256）连同原文一并下发（可存于data-signature属性、隐藏字段或单独接口返回）。提交时前端附上原文+签名，服务端用公钥/密钥重新计算并比对。

• 适用场景：表单提交、评论发布、配置项保存等需强校验的环节
• 注意：签名必须基于原始HTML字符串（建议先标准化：去除空白、统一引号、转义特殊字符），否则DOM序列化差异会导致验签失败
• 避免仅在前端做签名——私钥绝不能暴露在浏览器中

嵌入不可见但可验证的内容指纹

服务端为富文本生成唯一摘要（如SHA-256哈希），Base64编码后插入HTML注释或自定义data-属性（如...）。提交时校验当前HTML内容哈希是否匹配该指纹。

• 优点：轻量、无密钥管理开销
• 局限：仅防篡改，不防重放；需防范攻击者删除或伪造data-fingerprint
• 增强做法：将指纹与用户ID、时间戳拼接后再哈希，提升唯一性与时效性

服务端主导渲染 + 客户端只读隔离

敏感富文本不交由前端自由编辑，而采用“服务端生成安全HTML + 前端仅渲染”的模式。编辑权限收归后台，前端通过API获取已清洗、已签名、已转义的只读内容（如用DOMPurify过滤+服务端签名）。

• 典型流程：用户申请编辑 → 后台返回带签名的富文本快照 → 前端展示并禁用contenteditable → 修改需走专用编辑接口，全程服务端校验
• 配合CSP策略（如script-src 'self'）可进一步阻断XSS导致的DOM劫持篡改

警惕纯前端“伪加密”陷阱

常见误区是用JS Base64、ROT13或简单AES（密钥硬编码）混淆HTML内容。这类方式完全无效——源码可见、密钥可提取、解密逻辑可逆，无法抵御任何有意篡改。

• Base64不是加密，只是编码；浏览器开发者工具中一眼可读
• 前端AES若密钥写死或从API明文获取，等同于裸奔
• 真正防护必须依赖服务端参与的密码学验证，且关键逻辑不可绕过

不复杂但容易忽略：防篡改的关键不在“锁住HTML”，而在建立“内容—凭证”的可信绑定，并让校验不可跳过。所有客户端操作都应视为不可信输入，最终以服务端验签/验哈希为准。