Notification API 本身不支持加密，因其仅接收明文参数并在系统层直接渲染；保护通知内容需服务端过滤、前端运行时解密（如 Web Crypto AES-GCM）及配套 HTTPS、权限控制等措施。
HTML5 浏览器通知（Notification API）本身不提供内容加密能力，它只是一个向用户展示简短消息的客户端接口，所有传入的标题、正文、图标等数据均以明文形式在浏览器内存和系统通知中心中呈现。所谓“加密通知内容”，实际是指在通知触发前，对敏感信息进行端到端保护，防止中间环节（如调试工具、恶意扩展、系统日志）直接读取原始消息。这需要结合前端加密逻辑与服务端协同设计，而非 Notification API 自身功能。
为什么不能直接加密 Notification 显示内容
Notification API 的 show() 方法接收的是已解密的字符串：
- 浏览器调用系统通知服务时，消息体已为纯文本，操作系统层无法识别或处理加密格式；
- 开发者工具（如 DevTools 的 Application → Notifications）可直接捕获并显示通知参数；
- 通知栏截图、屏幕录制、辅助工具等均可获取最终渲染结果，加密显示层无意义。
可行的“通知内容保护”策略
重点不是加密通知本身，而是控制谁能看到什么、何时看到、看到多少：
- 服务端预过滤：敏感字段（如订单号、金额、手机号）不在推送 payload 中下发，仅发 ID 或摘要，点击通知后跳转至需登录验证的页面再加载详情；
-
前端运行时解密：推送加密后的 base64 字符串（如 AES-GCM 加密），在页面上下文中使用 Web Crypto API 解密并调用
new Notification()，确保密钥不随通知传输（例如从 IndexedDB 安全读取或由用户输入派生）； -
混淆+时效性控制：对非关键字段做简单 Base64 或 ROT13 处理，并设置
timestamp和data字段绑定唯一请求 ID，服务端校验该 ID 是否已被消费，防止重放或截获复用。
一个轻量级前端解密示例（AES-GCM）
假设后端推送了加密后的通知正文 ciphertext: "..." 和 nonce：
→ 前端用已安全存储的密钥（如通过 deriveKey 从用户密码生成）调用 crypto.subtle.decrypt()；
→ 解密成功后立即创建通知：
<!-- 仅示意，密钥管理需更严谨 -->
const decrypted = await crypto.subtle.decrypt(
{ name: 'AES-GCM', iv: nonce },
key,
ciphertext
);
const text = new TextDecoder().decode(decrypted);
new Notification('新消息', { body: text }); // 此时才暴露明文
必须同步做的安全配套措施
- 启用 HTTPS：防止推送消息在传输中被中间人窃取或篡改；
- 限制 Service Worker 权限：避免恶意脚本劫持 push event 并窃取解密逻辑；
- 禁用敏感信息缓存：在
push事件中不将原始密文写入 localStorage 或 console； - 通知点击后强制身份校验：跳转页需重新验证 session 或 MFA，不信任通知携带的任何上下文。
