HTML5视频加密依赖EME+DRM或MSE+Web Crypto实现，非HTML5原生能力；主流方案用AES/CENC加密分片，浏览器CDM解密；轻量方案需自管密钥与解密逻辑；须配合HTTPS、签名URL等防护，禁用伪加密。
HTML5 本身不提供原生的视频流加密能力，所谓“HTML5 加密播放”，实际是通过标准 Web 技术栈（如 MSE、EME、AES 解密逻辑）配合服务端加密策略实现的端到端保护。核心不是 HTML5 自己加密，而是浏览器支持解密已加密的内容。
使用 Encrypted Media Extensions（EME）+ DRM 方案
这是目前主流、合规、跨平台的视频加密播放方案，适用于点播与直播场景：
- 服务端对视频切片（如 HLS 的 .ts 或 DASH 的 .mp4 分片）用 AES-128 或 CENC（Common Encryption）加密
- 前端通过 MediaKeys 和 MediaKeySession 接口请求许可证（License），由 DRM 服务商（如 Google Widevine、Apple FairPlay、Microsoft PlayReady）验证授权并返回解密密钥
- 浏览器内置 CDM（Content Decryption Module）完成透明解密与播放，开发者无需接触明文密钥
- HLS 可结合
#EXT-X-KEY指令声明加密方式；DASH 使用ContentProtection元素描述 DRM 信息
自定义 AES 解密 + Media Source Extensions（MSE）
适合对 DRM 成本敏感、可控环境下的轻量级保护（如内网系统或自有 App WebView）：
- 服务端用 AES-CBC 或 AES-GCM 对视频分片加密，并将 IV、密钥标识等元数据随 manifest 一起下发（绝不传原始密钥）
- 前端用 Web Crypto API（如
subtle.decrypt()）在内存中解密二进制分片，再通过 MSE 动态注入SourceBuffer - 需自行管理密钥获取逻辑（如 JWT 鉴权后请求密钥接口）、错误重试、缓冲控制，开发成本较高且无法防内存 dump
- 注意：不能直接解密并写入
，必须走 MSE 流式拼接
传输层与访问控制协同加固
加密只是环节之一，需搭配其他手段提升整体安全性：
立即学习“前端免费学习笔记（深入）”；
- HTTPS 强制启用，防止视频 URL 或密钥被中间人劫持
- Token 化 URL：每个视频分片链接携带时效性签名（如 HMAC-SHA256），服务端校验后再响应内容
- Referer / UA / IP 限流校验，结合风控策略识别异常下载行为
- 禁用右键、禁用开发者工具录屏（虽不能完全阻止，但提高盗录门槛）
不推荐的“伪加密”做法
这些方式看似简单，实则几乎无防护效果，容易误导：
- 仅靠 JS 混淆或 base64 编码视频 URL —— 浏览器网络面板可直接捕获真实地址
- 前端硬编码密钥并 AES 解密 —— 密钥可被反编译或内存提取
- 用 Canvas 帧绘制替代
标签 —— 仍可被屏幕录制或 GPU 内存抓取 - 禁用上下文菜单或 F12 —— 完全无法阻止有经验的攻击者
真正安全的 HTML5 视频流播放，依赖标准协议支持（EME/DASH/HLS）、可信 DRM 服务和严谨的服务端策略。技术选型应根据版权等级、终端覆盖、预算和运维能力综合判断。商用高价值内容务必采用 Widevine/FairPlay 等成熟 DRM；内部系统可考虑 MSE + Web Crypto 自研轻量方案，但需接受其防护边界。
