Cookie存储Token如何防止XSS攻击？

Question

如何在使用 Cookie 存储 Token 时有效防范 XSS 攻击？若前端 JavaScript 可通过 `document.cookie` 读取 Token，攻击者注入恶意脚本后即可窃取凭证。虽然设置 `HttpOnly` 标志能禁止脚本访问，但若缺乏 `Secure` 和 `SameSite` 配置，仍可能面临中间人攻击或 CSRF 风险。如何综合运用这些属性，并结合前端安全策略（如 CSP），在保障功能正常的同时最大限度防御 XSS 导致的 Token 泄露？

Answer 1

如何在使用 Cookie 存储 Token 时有效防范 XSS 攻击

随着现代 Web 应用广泛采用基于 Token 的身份认证机制，将 Token 存储于 Cookie 成为一种常见实践。然而，若未正确配置 Cookie 属性与前端安全策略，极易导致 XSS（跨站脚本攻击）引发的 Token 泄露。本文从基础到深入，系统性地探讨如何综合运用 HttpOnly、Secure、SameSite 等 Cookie 属性，并结合 CSP（内容安全策略）、输入验证等前端防御手段，构建纵深防御体系。

1. 基础防护：Cookie 核心安全属性详解

Cookie 安全配置是防止 Token 被窃取的第一道防线。以下是关键属性及其作用：

属性	作用	建议值
HttpOnly	禁止 JavaScript 访问 Cookie，抵御 XSS 盗取	true
Secure	仅通过 HTTPS 传输，防止中间人劫持	true
SameSite	限制跨站请求携带 Cookie，缓解 CSRF	Strict 或 Lax
Path	限定 Cookie 作用路径	/api
Domain	明确指定域名范围	避免泛域名设置

示例设置方式（Node.js + Express）：

res.cookie('token', jwtToken, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict',
  maxAge: 24 * 60 * 60 * 1000, // 24小时
  path: '/api'
});

2. 深入分析：XSS 攻击路径与 Cookie 风险关联

XSS 攻击的本质是恶意脚本在用户浏览器中执行。当 Token 可通过 document.cookie 读取时，攻击者可轻易注入如下脚本：

fetch('/log?data=' + document.cookie);

即使设置了 HttpOnly，若缺失 Secure，在非 HTTPS 环境下仍可能被中间人嗅探；而缺乏 SameSite 则可能被用于 CSRF 攻击，实现会话劫持。因此，单一属性不足以构建完整防护。

• XSS → 获取非 HttpOnly Cookie → 直接泄露 Token
• 中间人攻击 → 明文传输 Cookie → Secure 缺失导致风险
• CSRF → 自动携带 Cookie → SameSite 配置不当引发越权操作

3. 综合防御：CSP 与前端安全策略协同

内容安全策略（Content Security Policy, CSP）是从源头遏制 XSS 的关键机制。通过限制脚本来源，可大幅降低恶意代码执行概率。

推荐的 CSP 头部配置示例：

Content-Security-Policy: 
  default-src 'self';
  script-src 'self' 'unsafe-inline' 'unsafe-eval';
  img-src *;
  style-src 'self' 'unsafe-inline';
  object-src 'none';
  frame-ancestors 'none';
  base-uri 'self';

生产环境应尽可能移除 'unsafe-inline' 和 'unsafe-eval'，改用 nonce 或 hash 策略。

4. 架构设计层面的纵深防御模型

真正的安全需贯穿前后端架构。以下流程图展示了从用户登录到 API 请求的完整安全链路：

graph TD A[用户登录] --> B{后端生成 JWT} B --> C[Set-Cookie: token=xxx; HttpOnly; Secure; SameSite=Strict] C --> D[前端发起API请求] D --> E[浏览器自动携带Cookie] E --> F[后端验证签名与有效期] F --> G[返回数据] H[XSS注入] --> I[尝试document.cookie] I --> J[因HttpOnly失败] K[CSRF尝试] --> L[因SameSite拦截]

该模型体现了“默认拒绝”原则，确保即使某一层被突破，其他层仍能提供保护。

5. 实践建议与常见误区

在实际项目中，开发者常陷入以下误区：

1. 仅设置 HttpOnly，忽略 Secure 导致开发环境泄露
2. SameSite 设置为 None 但未同时启用 Secure
3. CSP 配置过于宽松，允许 CDN 不可信脚本
4. 前端框架动态插入 HTML 未进行转义处理
5. Token 过期时间过长，增加暴露窗口
6. 未对 Cookie 进行绑定（如 IP、User-Agent）增强校验
7. 日志系统记录 Cookie 内容造成二次泄露
8. 子域名共享 Cookie 导致横向提权风险
9. 缺乏定期安全审计与自动化扫描
10. 未启用 Subresource Integrity (SRI) 验证第三方资源