html5无法防篡改，必须由后端校验：accept和filereader仅作前端辅助，可被绕过；服务端需重算哈希、验签名、解析真实mime类型和文件内容。
HTML5 本身不提供文件上传后的防篡改能力——它只负责把文件从用户设备发到服务器，校验和防护必须由后端完成。前端能做的只有辅助性限制（如类型、大小、基础哈希），但这些全可被绕过。
为什么 accept 和 FileReader 无法防篡改
很多人误以为设置 accept="image/*" 或用 FileReader 读取文件头就能阻止恶意文件上传，其实不然：
-
accept仅影响浏览器文件选择对话框的过滤，用户仍可手动输入任意文件或拖拽绕过 -
FileReader.readAsArrayBuffer()计算的客户端哈希（如 SHA-256）可被伪造：攻击者在上传前用工具替换文件内容，再伪造对应哈希值提交 - 浏览器禁用 JavaScript 后，所有前端校验逻辑直接失效
必须依赖后端做文件完整性校验
真正有效的防篡改，是服务端收到文件后立即验证其内容一致性。常见做法包括：
- 接收文件后，用服务端语言（如 Python 的
hashlib、Node.js 的crypto.createHash()）重新计算完整文件哈希，并与前端提交的哈希比对（注意：该哈希仅作参考，不能替代服务端重算） - 对关键文件（如固件、配置模板）使用数字签名：上传时附带
.sig签名文件，服务端用公钥验证签名有效性 - 限制文件 MIME 类型解析结果（非请求头里的
Content-Type），例如用file命令或python-magic检查真实类型 - 对图片类文件，调用
identify（ImageMagick）或PIL.Image.open()尝试解析，捕获异常以识别伪装文件
前端可做的合理辅助措施
虽然不能防篡改，但前端能提升体验并增加攻击成本：
立即学习“前端免费学习笔记（深入）”；
- 用
input[type="file"]的multiple和maxSize属性做初步大小拦截（配合后端二次检查） - 上传前用
FileReader读取前 1024 字节，匹配已知文件魔数（如89 50 4E 47对应 PNG），拒绝明显不匹配的文件 - 上传时携带
X-File-Hash请求头（如sha256=abc123...），服务端将其作为日志字段留存，便于事后审计比对 - 禁用表单自动提交，统一走
fetch或XMLHttpRequest，便于添加自定义 header 和错误处理
const input = document.querySelector('input[type="file"]');
input.addEventListener('change', async (e) => {
const file = e.target.files[0];
if (!file) return;
// 读取前 4 字节判断魔数
const buffer = await file.slice(0, 4).arrayBuffer();
const view = new Uint8Array(buffer);
const magic = Array.from(view).map(b => b.toString(16).padStart(2, '0')).join(' ');
if (magic !== '89 50 4e 47') {
alert('仅支持 PNG 文件');
return;
}
const formData = new FormData();
formData.append('file', file);
// 附带哈希供服务端记录（非校验依据）
const hash = await crypto.subtle.digest('SHA-256', await file.arrayBuffer());
const hexHash = Array.from(new Uint8Array(hash))
.map(b => b.toString(16).padStart(2, '0'))
.join('');
const res = await fetch('/upload', {
method: 'POST',
body: formData,
headers: { 'X-File-Hash': `sha256=${hexHash}` }
});
});
真正的防线永远在服务端：哪怕前端做了十层校验，只要后端没重算哈希、没验签名、没解析真实格式，文件就依然可能被篡改或执行。别让“前端做了”变成“已经安全了”的错觉。
