CSRF 攻击利用浏览器自动携带登录 Cookie特性，无需窃取凭证即可假冒用户操作。核心条件为：用户已在目标网站登录且 Cookie 未设置 SameSite=Strict/None；服务端仅验证登录状态不校验请求源或随机验证 Token；攻击者能构造符合接口要求的请求格式。 防御需多重加固：1. Cookie 添加 SameSite=Strict; Secure; HttpOnly 防止跨域脚本读取，但后者仍无法阻止自动携带，需配合 2. CSRF Token 机制（双向验证） 3. 严格验证请求来源和随机参数。特别需注意：JSON 接口若依赖前端传入 Token 仍存在风险，GET 请求不可用于修改状态（如删除账户），而 POST 可exploit但需结合防治措施。实验表明，同主机的跨端口请求可有效突破 CORS 限制，说明需要区分 Origin 和 SameSite 的边界保护。攻击成功后用户不会察觉异常，损失可能需数日才发现。

用户登录后，服务端生成Session并通过Cookie传递给浏览器，浏览器会自动携带该Cookie与后续请求。此机制易被CSRF攻击利用。防御需多维度设置：HttpOnly防止XSS窃取Cookie值，但无法阻止攻击通过网络劫持成功；SameSite=lax可限制部分跨站请求但需结合Csrf Token；Secure强制HTTPS传输。推荐配置__Host前缀并设置Path=/和Secure，将Cookie限定当前主机的根路径。需注意SameSite=lax仍可能因同站漏洞导致 CSRF，且 scratches 教程的复查验证步骤对完整性至关重要。常见误区：HttpOnly不阻止浏览器自动发送，SameSite无法替代服务端Csrf验证。需结合Session管理，主动更新权限或注销异常会话。