HTML5通知加密方法详解【采撷】

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《HTML5通知内容加密方法【采撷】》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

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，不信任通知携带的任何上下文。

本篇关于《HTML5通知加密方法详解【采撷】》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！