如何实现安全的PUT、DELETE请求？笔记后端安全方案咨询

针对你遇到的笔记增删查操作的安全风险，除了你提到的额外参数方案，还有这些更成熟的解决思路：

1. 严格对应HTTP标准方法 #

把不同操作绑定到标准HTTP方法上，从根源上区分操作类型：

• GET /notes：仅用于获取用户所有笔记（只读操作，无数据修改副作用）
• POST /notes：创建新笔记
• DELETE /notes/{note_id}：删除指定笔记

浏览器对DELETE这类非GET/POST的方法有更严格的限制，普通恶意表单无法直接触发，能大幅降低CSRF攻击的可能性。

2. 启用CSRF令牌验证 #

这是防护CSRF攻击的标准方案：

• 后端在用户登录后，生成一个随机唯一的CSRF令牌，存储在用户会话中
• 前端在提交表单或发送AJAX请求时，必须在请求头（比如X-CSRF-Token）或者表单隐藏字段里带上这个令牌
• 后端接收请求时，比对请求中的令牌和会话存储的令牌，不一致则直接拒绝请求

恶意网站无法获取当前用户的有效CSRF令牌，自然没法构造合法的修改请求。

3. 设置SameSite Cookie属性 #

给用户的会话Cookie添加SameSite属性：

• 设为SameSite=Strict：完全禁止第三方网站携带该Cookie，只有当前域名的请求才会附带
• 设为SameSite=Lax：允许部分安全的跨站GET请求携带Cookie，但POST、DELETE这类修改型请求不会

这样就算恶意网站构造了诱骗表单，用户提交时浏览器也不会带上会话Cookie，后端会判定用户未授权，拒绝执行操作。

4. 验证请求来源域名 #

检查请求的Origin或Referer请求头：

• Origin头会明确显示请求发起的域名，后端只允许来自自身域名的请求通过
• 注意：部分场景下Referer可能被浏览器隐藏，优先用Origin，同时兼容没有Origin的旧环境

5. 敏感操作添加二次验证 #

对于删除这类高风险操作，可以要求用户进行二次身份验证：

• 比如输入当前登录密码、发送验证码到绑定的邮箱/手机号
• 就算CSRF攻击绕过了前面的防护，也需要用户主动完成额外验证才能执行操作，能彻底避免意外数据丢失

内容的提问来源于stack exchange，提问作者a-aleksandr