HTML5拖拽上传需前端JavaScript加密（如Web Crypto API的AES-GCM），密钥须动态派生或安全下发，加密在ArrayBuffer读取后、上传前完成；服务端严格解密验证，全程强制HTTPS。
HTML5本身不提供文件加密功能，拖拽上传的文件若需加密，必须在前端用JavaScript实现加密逻辑（如AES），再将密文上传；服务端接收后解密。单纯依赖HTML5拖拽API无法加密文件内容。
前端加密是唯一可行路径
浏览器环境不支持直接调用系统级加密模块，所有加密操作必须由JS完成：
- 使用成熟Web Crypto API（
window.crypto.subtle）进行AES-GCM等现代加密，避免手写或引入不安全的第三方库 - 密钥不能硬编码，建议通过用户输入派生（如PBKDF2 + password），或由服务端动态下发（需HTTPS+身份校验）
- 加密应在文件读取为
ArrayBuffer后、上传前执行，避免明文内存残留（可及时fill(0)清空缓冲区）
拖拽过程不涉及加密，但影响数据准备时机
拖拽事件（drop）仅提供DataTransfer.files，此时文件仍是原始二进制：
- 立即用
FileReader.readAsArrayBuffer()读取，不要转成base64（体积膨胀33%，且base64字符串更难安全擦除） - 大文件需分块加密+流式上传，防止内存溢出；可结合
ReadableStream与TransformStream实现边读边加 - 拖拽多个文件时，逐个独立加密，勿合并后统一处理（失败时难以定位和重传）
服务端必须验证并严格解密
前端加密只是传输保护，服务端才是可信边界：
立即学习“前端免费学习笔记（深入）”；
- 拒绝未携带加密元数据（如IV、算法标识、认证标签）的请求，防止降级攻击
- 解密失败必须返回通用错误（如400 Bad Request），不暴露“密钥错误”或“IV不匹配”等细节
- 解密后的文件临时存储路径需权限隔离，处理完立即删除明文，禁用缓存和日志记录原始内容
这些坑务必避开
看似合理实则危险的操作：
- 用localStorage存用户密码派生的密钥——易被XSS窃取，应仅内存驻留
- 对整个File对象调用JSON.stringify()——会丢失二进制数据，且触发不可控序列化
- 上传前用MD5/SHA1校验完整性——哈希值无法防篡改，应使用AEAD模式的认证标签
- 在HTTP页面中启用加密上传——密钥可能被中间人劫持，强制HTTPS
