后台删用户改成 POST 提交并校验表单凭证，挡的是哪一类攻击

这类改动挡的是跨站请求伪造。有内容系统把后台的用户删除与状态切换改成 POST 提交并校验表单安全凭证，官方说明目的就是防止跨站请求伪造导致用户被误删或状态被改。它利用的弱点是：浏览器发请求时会自动带上登录态，攻击者诱导已登录管理员点一下，就能冒充他发出操作。

被改掉的原来是什么样

过去这类状态变更可能挂在简单的链接请求上——点开一个地址就执行删除。这种写法的问题是请求本身不带「你是不是真的想删」的证明，只要带着有效登录态就会被认账。

为什么 GET 上的删除操作危险

危险点在于它会「被顺带触发」。页面里一张图、一个跳转都能让浏览器替你发一个链接式请求，而登录态自动附上。跨站请求伪造不需要拿到密码，它借的是你已经登录这件事。把删除从这种易触发的形态移走，是处置的第一步。

表单凭证校验校验了什么

把动作移到 POST 只是第一层，真正拦住伪造的是随表单一起校验的凭证。

光有 POST 挡不住精心构造的伪造请求，凭证校验才是关键那道闸。

为什么凭证比请求方法更关键

把动作移到 POST 只是把「随手可触发」变成「要构造」，攻击门槛升高但没消除。真正区分合法操作与伪造的，是服务端是否校验了一个只随正常表单签发、外部页面拿不到的凭证。没有这一步，精心构造的跨站请求照样带着登录态溜进来。所以顺序是先移走易触发形态，再用凭证把口子真正封住。

站内后台的三层防护

站内把不同风险分到不同层。reCAPTCHA/验证码管的是机器批量提交，敏感词过滤、关键词替换与内容审核管的是内容风险，认证与转义类防护收住注入与跨站脚本。删用户、改状态这类高危操作还要能查到谁在什么时候做的，追责与校验配合才闭环。跨站请求伪造归到凭证这一层，别指望内容过滤帮你挡它，也别把验证码当成万能闸。

常见问题

问：改成 POST 就安全了吗？ 不够。POST 只是不易被链接触发，仍需表单凭证校验才能识破伪造提交，两层要一起做。

问：验证码能挡跨站请求伪造吗？ 不能直接。验证码针对机器批量提交，跨站请求伪造靠的是有效登录态，两层各管一类风险。

问：高危操作为什么还要留记录？ 校验防的是被伪造执行，记录防的是事后无法追责，两者互补，缺一层都会留下说不清的口子。