标签不提供 csrf 防护，其内表单需显式嵌入服务端生成的 token 字段，fetch 请求须手动携带 token，open 状态等前端状态不可用于安全校验。
dialog 标签本身不参与 CSRF 防护
<dialog></dialog> 是一个纯粹的 UI 容器，浏览器不会自动为它注入 token、绑定 session 或拦截提交行为。它和 <div> 一样，只是渲染结构——如果里面放的是表单，那防 CSRF 的责任仍在表单本身；如果发起的是 fetch 请求，那 token 必须手动携带。
<p>常见错误现象：把 <code><dialog></dialog> 当成“安全沙盒”，以为弹窗里的操作天然隔离 CSRF 风险，结果用户点击确认按钮后触发的请求根本没带 token，服务端直接返回 403 Forbidden 或 Invalid CSRF token。
- dialog 不会自动继承父页面的 CSRF token，也不会阻止脚本读取页面中已存在的
<input name="__RequestVerificationToken"> - 若 dialog 内容通过 JavaScript 动态插入（如
dialog.innerHTML = ...），且模板里漏了 token 字段，就等于裸奔 - 用
showModal()打开的 dialog 仍处于同一 document 上下文，所有 DOM 查找、事件监听、token 提取逻辑照常生效
在 dialog 内嵌表单时必须显式插入 token 字段
只要表单走传统 submit（非 AJAX），CSRF token 就得是 <form></form> 的直接子元素、位于提交按钮之前，且字段名与后端约定严格一致。Laravel 用 _token，ASP.NET Core 用 __RequestVerificationToken，Django 用 csrfmiddlewaretoken ——不能靠 JS 拼字符串硬写，也不能指望框架自动补全。
正确做法是后端渲染时就把 token 写进 dialog 模板，而不是前端 JS 动态生成值：
<dialog id="confirm-transfer"><form action="/api/transfer" method="post">
<input type="hidden" name="__RequestVerificationToken" value="abc123...xyz789"><input type="hidden" name="to" value="attacker"><button type="submit">确认转账</button>
</form>
</dialog>
- 字段必须在
<form></form>内部，不能放在<dialog></dialog>顶层或<div> 里 <li>value 值必须每次页面加载时由服务端生成，禁止缓存、禁止 localStorage 回填、禁止写死</li> <li>如果 dialog 是通过 <code>fetch()加载 HTML 片段，需确保后端接口也执行 token 渲染逻辑（例如 ASP.NET Core 的 Partial View 也要调用@Html.AntiForgeryToken()） - 从页面任意位置取值都行，只要 DOM 已存在：
document.querySelector('input[name="__RequestVerificationToken"]').value - 推荐统一封装提取逻辑，避免多个 dialog 重复写相同代码
- header 名需匹配后端要求：ASP.NET Core 默认认
RequestVerificationToken，Spring Security 可能要X-CSRF-TOKEN，别凭感觉写 - 若服务端用
[AutoValidateAntiforgeryToken]（而非仅[ValidateAntiForgeryToken]），则 header 和 form body 两种方式都支持；否则只认 form body - dialog 的
open属性可被 JS 随意修改，无法作为服务端校验依据 - 前端禁用按钮、加 loading 状态，只能防误点，不能防伪造请求
- SameSite Cookie、CSP、Referer 检查这些辅助手段，都替代不了 token 本身的动态性与绑定 session 的强制性
dialog 中发起 fetch 请求时 token 必须手动塞进 headers
浏览器不会因为请求来自 <dialog></dialog> 就自动附加 cookie 或 hidden 字段。fetch / XMLHttpRequest 发起的 POST 请求，token 只能靠 JS 主动提取并传入 headers 或 body。
典型错误写法：fetch('/api/transfer', { method: 'POST' }) —— 完全没带 token，服务端校验必挂。
不要用 dialog 的 open/close 状态做安全判断
有人试图用 dialog.open === true 或监听 close 事件来“确认用户真实意图”，这毫无意义。CSRF 攻击不依赖用户是否看到弹窗，而是利用浏览器自动携带 cookie 的机制发起静默请求。攻击者完全可以构造一个不可见的 <dialog hidden></dialog>，再用 JS 触发 showModal() + 自动 submit。
真正起作用的只有两点：token 是否存在、是否有效。其他都是干扰项。
