后台CSRF防护：登录成功以后，发布和暂停按钮仍要校验请求

登录态不能代替敏感操作的请求校验。本文介绍 CSRF 令牌的生成、传递和验证，并说明常见的误用方式。

后台发布、修改配置和暂停任务都依赖登录状态。如果浏览器会自动附带登录 Cookie，恶意网页就可能尝试诱导它发送操作请求。仅检查“用户已经登录”还不够。

给修改操作加令牌

服务端生成不可预测的 CSRF 令牌，与当前会话关联。表单用隐藏字段提交，异步请求可通过自定义请求头传递；服务器先检查登录与令牌，再执行修改。令牌缺失或不匹配时应拒绝操作并给出重新加载提示。

避免几个常见误区

不要通过 GET 地址执行发布或删除，也不要把令牌放在网址里，减少历史记录和日志泄露。SameSite Cookie 可以提供一层保护，但不应被当成所有场景下的唯一方案。输入转义和防止脚本注入也仍然需要保留。

兼顾多标签页体验

令牌策略要与会话生命周期匹配。若每次请求都立即作废旧令牌，多标签页和返回上一页可能出现误拦截。选择框架成熟实现通常比自创协议稳妥；不能为了消除报错而直接取消校验。

验收时测试正常点击、缺少令牌、错误令牌和登录过期四种情况。失败应保持数据不变，成功只执行一次。页面按钮变色负责反馈状态，服务器端的权限与令牌校验才负责决定操作能否发生。

参考资料

资料核对：2026年10月27日。本文为文档综合与操作建议，未宣称完成本站实测。

OWASP CSRF 防护

MDN 内容安全策略