SessionStorage 本身不能防止 CSRF，真正起防护作用的是服务端生成并校验的 CSRF Token；SessionStorage 仅作为前端安全暂存 Token 的方式，需配合严格规范与后端协同。

SessionStorage 本身不能防止 CSRF，它只是个临时存储容器。真正起防护作用的是服务端生成并校验的 CSRF Token，而 SessionStorage 可作为前端安全暂存该 Token 的一种方式——前提是配合严格的操作规范和后端协同。

为什么不用 localStorage 或 Cookie 存 CSRF Token

localStorage 持久存在、易被 XSS 读取，一旦页面存在漏洞，攻击者可直接窃取 Token 并伪造请求；普通 Cookie 若未设 HttpOnly=false + SameSite=Lax/Strict，可能被自动携带导致 CSRF，且 JS 可读时同样面临 XSS 风险。SessionStorage 的天然优势在于：只在当前标签页会话有效、关闭即清空、不随请求自动发送，规避了自动携带和长期暴露问题。

正确将 CSRF Token 写入并读取 SessionStorage

服务端需在渲染 HTML 时，把动态生成的 Token 注入页面（如通过内联 script 或 data 属性），前端再提取存入 sessionStorage ——绝不能从 URL、API 响应体或 localStorage 中读取。

Browser Session Manager

使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能

下载

• 服务端示例（Django 模板）：<script>sessionStorage.setItem('csrf_token', '{{ csrf_token }}');</script>
• 前端读取并用于表单提交：document.getElementById('myForm').addEventListener('submit', e => { e.target.appendChild(Object.assign(document.createElement('input'), { type: 'hidden', name: 'csrf_token', value: sessionStorage.getItem('csrf_token') })); });
• 用于 AJAX 请求：headers: { 'X-CSRF-Token': sessionStorage.getItem('csrf_token') }
• 每次页面加载都应重新写入，避免多标签页间 Token 失效或错用

关键安全约束必须满足

仅靠 sessionStorage 存储不构成防护，以下三点缺一不可：

立即学习“前端免费学习笔记（深入）”；

• Token 必须由服务端为每个用户 session 动态生成，且一次一换（尤其敏感操作前可刷新）
• 服务端校验时，必须比对当前 session 中绑定的 Token 值，而非仅检查是否存在或格式是否合法
• 前端绝不硬编码 Token，不跨标签页共享 sessionStorage（各 tab 独立），不通过 postMessage 向其他源传递
• 若页面支持离线或长时间停留，需监听 pagehide/unload 事件主动清理，或设置 Token 过期时间并与服务端同步

比单纯存 sessionStorage 更稳妥的做法

对于现代 SPA 应用，推荐组合策略：

• 首次加载时，由服务端通过 Set-Cookie: XSRF-TOKEN=xxx; SameSite=Lax; Secure 设置 Token（非 HttpOnly），让前端从 document.cookie 读取并存入 sessionStorage
• 所有 POST/PUT/DELETE 请求，统一由请求拦截器自动注入 X-XSRF-TOKEN 请求头
• 服务端使用标准中间件（如 Express 的 csurf 替代方案 csrf-protection）校验该头与 session 中值的一致性
• 表单仍保留隐藏字段作为降级方案，确保无 JS 时也能提交