在 Express 框架中，你会采取哪些措施来防御 CSRF 攻击？
考察说明
考查对 Express 应用中 CSRF 攻击原理及常见防护方案的理解与落地能力。
回答思路
- 【回答框架 1】CSRF 攻击利用浏览器自动携带 Cookie 的特性，诱导用户在已登录状态下向目标站点发送伪造请求。防护核心是确保请求来源可信且携带攻击者无法预知的令牌。
- 【回答框架 2】常用方案一：同步令牌模式。服务端生成随机 token 存入 session，渲染表单或接口时下发，客户端提交时携带，服务端比对一致才放行。Express 中可结合 csurf 中间件实现，但需注意该中间件已停止维护。
- 【回答框架 3】常用方案二：双重提交 Cookie。服务端将 token 写入 cookie，同时要求请求头或表单字段携带相同 token，服务端校验两者一致即可。此方案无需存储 session，适合分布式环境，但依赖 Cookie 的 SameSite 属性增强安全性。
- 【回答框架 4】补充措施：设置 SameSite=Lax 或 Strict 限制跨站携带 Cookie；校验 Origin 或 Referer 头；对敏感操作要求自定义请求头或二次验证。
- 【回答框架 5】无状态 API 场景优先采用双重提交 Cookie 或 JWT 携带 CSR F token，避免 session 存储带来的扩展性问题。
- 【关键点 1】CSRF 防护本质是校验请求来源与携带的不可预测令牌。
- 【关键点 2】同步令牌模式需要服务端存储，双重提交 Cookie 无需存储。
- 【关键点 3】SameSite 属性可减少大多数 CSRF 攻击，但不能完全替代 token 机制。
- 【关键点 4】Express 中推荐使用 csurf 或自行实现双重提交 Cookie 逻辑。
- 【关键点 5】敏感操作应同时考虑 CSRF 与点击劫持等风险。
- 【易错点 1】不要仅依赖 Cookie 一致性无 token 校验，否则可能被挟持子域或 XSS 绕过。
- 【易错点 2】对外提供 REST API 时，若仅设置 CORS 不处理 CSRF，可能仍存在风险。
- 【易错点 3】使用 csurf 中间件需注意其兼容性与维护状态，避免引入已废弃依赖。