HTML表单设计安全：防御CSRF的页面标记指南-html教程-PHP中文网

csrf token 必须由服务端动态生成并绑定当前 session，禁止写死或缓存；字段名与位置需严格匹配框架约定，ajax 请求须显式携带，samesite cookie 仅为辅助加固而非替代方案。

html表单设计安全：防御csrf的页面标记指南

CSRF Token 必须由服务端动态生成，不能写死或缓存

HTML 本身不防 CSRF，input type="hidden" 标签只是个容器，值必须每次页面渲染时由服务端实时生成、绑定当前 session，并随页面一并下发。写死的字符串（如 value="abc123"）或从 localStorage 读取的 token 等同于没防。

常见错误现象：403 Forbidden 或 Invalid CSRF token 频繁出现，尤其在多标签页切换、页面刷新后——本质是服务端校验时发现 token 已失效、过期或被重复使用（如启用了一次性模式）。

禁止模板层缓存含 token 的 HTML 片段；Nginx/Apache 的页面级缓存需排除含表单的路由
Token 生命周期建议 ≤ 15 分钟，且与用户 session 绑定；Django 默认用 session 存储，Express 的 csurf 中间件默认存在内存里（生产环境需配 Redis）
ASP.NET Core 的 @Html.AntiForgeryToken()、Laravel 的 {{ csrf_token }}、Symfony 的 form_widget(form._token) 都是安全生成方式，别手写

表单 hidden 字段名和位置有明确要求

Token 字段必须放在 <form></form> 内部、且在提交按钮之前，字段名需和服务端约定一致。名称不匹配或位置错位会导致服务端根本收不到 token 值。

不同框架默认字段名不同：

Laravel Collective：默认用 _token，对应 <input name="_token" value="...">
Django：默认 csrfmiddlewaretoken，但常通过 {% csrf_token %} 渲染为 <input name="csrfmiddlewaretoken" ...>
Symfony：默认 _token，可自定义为 csrf_field_name 选项
ASP.NET Core：__RequestVerificationToken，必须搭配 [ValidateAntiForgeryToken] 特性

不要手动改字段名却不同步服务端配置——否则校验永远失败。

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

AJAX 请求必须显式携带 token，浏览器不会自动附带

表单 submit 会自动把 hidden 字段发过去，但 fetch / XMLHttpRequest 不会。前端 JS 必须主动提取 token 并塞进请求体或 header，否则服务端收不到。

推荐统一用 <meta name="csrf-token" content="..."> 埋点，比从 input[name="_token"] 里取更可靠（避免多个表单时取错 DOM 节点）。

提取方式：document.querySelector('meta[name="csrf-token"]')?.getAttribute('content')
fetch 示例：headers: { 'X-CSRF-Token': token }，注意服务端是否支持该 header 名（Django 需设 CSRF_HEADER_NAME = 'HTTP_X_CSRF_TOKEN'）
禁止把 token 拼进 URL 参数或硬编码在 JS 里——URL 会被日志、代理、Referer 泄露；JS 字符串在 XSS 下可被直接读取

SameSite Cookie 不是 CSRF 的替代方案，只是加固项

SameSite=Lax 能挡住部分 GET 类 CSRF（比如图片链接触发），但对 POST 表单、fetch JSON 请求、甚至某些浏览器的自动表单提交行为无效。它解决不了“同站子域名互相调用”这类场景（如 admin.example.com 被 blog.example.com 利用）。

更现实的问题是兼容性：