FastAPI中JWT Bearer Token安全存储、Cookie设置与CSRF防护疑问

1. 会话Cookie的设置与隐身模式处理 #

设置会话Cookie是后端的职责——Cookie的核心安全属性（如HttpOnly、Secure、SameSite）只能通过后端返回的Set-Cookie响应头配置，前端无法操作这些属性。

隐身模式下，浏览器会创建独立临时会话，所有Cookie仅在当前隐身窗口生命周期内有效，关闭窗口后自动清除。正确做法是后端在登录成功后，通过Set-Cookie头直接下发Cookie，而非让前端自行存储Token。FastAPI示例代码如下：

from fastapi import Response

@app.post("/login")
async def login(response: Response):
    access_token = "my_token"  # 实际应为生成的合法JWT
    response.set_cookie(
        key="access_token",
        value=access_token,
        httponly=True,
        secure=True,  # 生产环境必须启用，仅允许HTTPS传输
        samesite="strict",
        max_age=3600  # 有效期1小时
    )
    return {"token_type": "bearer"}

2. Cookie与LocalStorage的区别及JWT存储建议 #

两者核心差异：

• 存储容量：Cookie最大约4KB，LocalStorage最大约5MB
• 自动携带：Cookie会随同域所有请求自动发送给服务器，LocalStorage需手动写入请求头/体
• 有效期：Cookie可通过max_age/expires设置过期时间，LocalStorage为永久存储（除非手动清除）
• 安全属性：Cookie支持HttpOnly、Secure、SameSite等安全配置，LocalStorage无此类属性
• 访问权限：非HttpOnly的Cookie可被前端+后端读取，LocalStorage仅能被前端JavaScript读取

JWT存储优先级：

• 首选带HttpOnly、Secure、SameSite=Strict/Lax属性的Cookie：HttpOnly属性可避免XSS攻击窃取Token，是最安全的存储方式。
• 若必须让前端读取Token内容（如解析用户信息），可存在LocalStorage，但需严格做XSS防护（如输入校验、内容转义、CSP配置）——LocalStorage易被XSS攻击窃取，风险更高。

3. CSRF防护的有效性判断 #

仅配置CORS和检查Origin头不足以完全抵御CSRF攻击：

• CORS的作用是限制前端能否读取跨域请求的响应，无法阻止恶意网站发送跨域请求（浏览器仍会自动携带Cookie）。
• 检查Origin头有一定防护作用，但存在局限性：部分请求（如GET请求）可能不带Origin头，且Origin在特定环境下可能被伪造。

完整的CSRF防护需结合两种手段：

1. SameSite Cookie属性：设置SameSite=Strict或Lax，限制Cookie仅在同域请求或安全跨域请求（如导航链接）中发送，直接阻断恶意网站的跨域请求携带Cookie。
2. CSRF Token验证：
   • 后端生成CSRF Token，存储在非HttpOnly的Cookie中（方便前端读取）。
   • 前端发起非GET请求时，将CSRF Token放入请求头（如X-CSRF-Token）或请求体。
   • 后端验证请求中的Token与Cookie中的Token是否一致，不一致则拒绝请求。

内容的提问来源于stack exchange，提问作者Javier Sánchez