CSRF 防护的性能影响有哪些，如何进行优化？

CSRF 防护在生产环境中确实会引入性能开销，但合理的架构设计可以在安全与性能之间取得平衡。理解开销来源并采用分层优化策略，是高并发场景下的关键能力。

CSRF 防护的性能开销来源

Token 生成与验证

CSRF Token 的生成依赖加密安全随机数生成器（CSPRNG）。以 Node.js 为例，crypto.randomBytes(32) 单次调用约 0.02ms，万次批量生成耗时约 234ms，即每秒可生成约 4 万个 Token。单次开销极低，但在 QPS 超过 5000 的高并发场景下，Token 生成会成为不可忽视的 CPU 消耗点。

Token 验证的开销取决于存储方式。纯字符串比对耗时微乎其微，但涉及数据库查询时，每次验证需要 10-50ms 的 I/O 延迟。在请求量大的写接口上，这意味着数据库连接池容易被占满。

会话加载与存储访问

传统 CSRF 防护要求在每个状态变更请求中加载会话，验证 Token 是否匹配。Spring Security 5 及更早版本默认在每次请求时加载 CsrfToken，即使该请求不需要 CSRF 校验（如 GET 请求）。Spring Security 6 已改为延迟加载（Deferred CsrfToken），仅在需要时才访问会话存储，显著降低了不必要的开销。

页面缓存失效

CSRF Token 是用户级别且动态生成的，包含 Token 的页面无法被 CDN 或反向缓存。这是常被忽视的性能影响——一个本可以命中缓存的页面，因为嵌入了 CSRF Token 而必须回源渲染。Cloudflare 的技术分析指出，CSRF Token 是页面级缓存最大的阻碍之一，尤其对于包含表单的页面。

核心优化策略

策略一：选择合适的 Token 存储方案

存储方式	读延迟	写延迟	扩展性	适用场景
内存	<1ms	<1ms	低	单实例、低流量
Redis	1-5ms	1-5ms	高	分布式系统、高流量
数据库	10-50ms	10-50ms	中	简单应用、低流量

生产环境推荐 Redis + 本地内存二级缓存。本地缓存命中时延迟 <0.1ms，未命中时回退到 Redis，兼顾性能与分布式一致性：

javascript
class CachedTokenService {
  constructor(redisClient) {
    this.redis = redisClient;
    this.localCache = new Map();
    this.localTTL = 300000; // 5 分钟本地缓存
    this.maxLocalSize = 10000;
  }

  async getToken(userId) {
    // L1: 本地内存
    const cached = this.localCache.get(userId);
    if (cached && Date.now() - cached.ts < this.localTTL) {
      return cached.token;
    }
    // L2: Redis
    const redisToken = await this.redis.get(`csrf:${userId}`);
    if (redisToken) {
      this._setLocal(userId, redisToken);
      return redisToken;
    }
    // L3: 生成新 Token
    const token = crypto.randomBytes(32).toString('hex');
    await this.redis.setex(`csrf:${userId}`, 3600, token);
    this._setLocal(userId, token);
    return token;
  }

  _setLocal(userId, token) {
    if (this.localCache.size >= this.maxLocalSize) {
      const oldest = this.localCache.keys().next().value;
      this.localCache.delete(oldest);
    }
    this.localCache.set(userId, { token, ts: Date.now() });
  }
}

策略二：使用 HMAC 无状态 Token 消除存储开销

传统 Token 需要服务端存储，每次验证都访问存储层。HMAC-based Token 将签名嵌入 Token 本身，验证时只需重新计算签名比对，无需任何存储访问：

javascript
const crypto = require('crypto');

class HMACTokenService {
  constructor(secret) {
    this.secret = secret;
  }

  // 生成：sessionId + 时间戳 + HMAC签名
  generate(sessionId) {
    const timestamp = Math.floor(Date.now() / 3600000); // 按小时粒度
    const payload = `${sessionId}:${timestamp}`;
    const signature = crypto
      .createHmac('sha256', this.secret)
      .update(payload)
      .digest('hex');
    return `${payload}:${signature}`;
  }

  // 验证：重新计算签名比对，无需存储
  validate(token, sessionId) {
    const [sid, timestamp, signature] = token.split(':');
    if (sid !== sessionId) return false;

    const payload = `${sid}:${timestamp}`;
    const expected = crypto
      .createHmac('sha256', this.secret)
      .update(payload)
      .digest('hex');

    // 检查当前小时和上一个小时的签名，容忍 Token 在小时边界附近生成
    const currentHour = Math.floor(Date.now() / 3600000);
    if (parseInt(timestamp) < currentHour - 1) return false;

    return crypto.timingSafeEqual(
      Buffer.from(signature),
      Buffer.from(expected)
    );
  }
}

HMAC Token 的优势在于验证延迟从 1-50ms（存储访问）降到 <0.1ms（纯计算），且无需维护 Token 存储的过期清理。Spring Security 的 CookieCsrfTokenRepository 和 Django 的 django.middleware.csrf 都支持类似的签名验证模式。缺点是 Token 无法主动撤销，需依赖较短的有效期。

策略三：避免不必要的 Token 生成

关键原则：安全请求（GET、HEAD、OPTIONS）不需要 CSRF Token 验证。确保框架配置仅对状态变更请求启用校验。

Spring Security 6 的 CsrfToken 延迟加载机制值得借鉴——Token 对象在请求处理链中懒初始化，仅当实际读取或校验时才触发生成和存储访问。Django 的 {% csrf_token %} 模板标签也有类似优化——仅在模板实际渲染该标签时才从会话中读取或生成 Token，GET 请求访问不含表单的页面时完全不触发 Token 逻辑。

策略四：解耦页面缓存与 Token 渲染

将 CSRF Token 从缓存的 HTML 中剥离，通过独立接口按需获取：

html
<!-- 可被 CDN 缓存的 HTML 模板 -->
<form action="/transfer" method="POST">
  <input type="hidden" name="_csrf" value="" id="csrfInput">
  <!-- 其他表单字段 -->
</form>

<script>
  // 页面加载后异步获取 Token
  fetch('/api/csrf-token', { credentials: 'same-origin' })
    .then(r => r.json())
    .then(data => {
      document.getElementById('csrfInput').value = data.token;
    });
</script>

这样页面主体可以被 CDN 缓存，Token 通过轻量 API 单独获取。另一种方案是使用 ESI（Edge Side Includes），在 CDN 边缘节点将 Token 片段注入缓存的页面，Nginx 和 Varnish 均支持此特性。

策略五：优先采用免 Token 方案

现代浏览器提供了不依赖 Token 的 CSRF 防护手段，可以显著降低服务端开销：

SameSite Cookie 属性：将 Cookie 设置为 SameSite=Strict 或 SameSite=Lax，浏览器自动阻止跨站请求携带 Cookie。Chrome 80+ 默认 SameSite=Lax，覆盖了大部分 CSRF 攻击场景。这是目前成本最低的防护方式，OWASP 将其列为推荐的 CSRF 防御手段之一。

Fetch Metadata 请求头：Chrome 和 Firefox 支持的 Sec-Fetch-Site、Sec-Fetch-Mode 等头，服务端可据此判断请求来源：

javascript
function isSafeRequest(req) {
  const site = req.headers['sec-fetch-site'];
  const mode = req.headers['sec-fetch-mode'];
  if (site === 'same-origin') return true;
  if (site === 'none' && mode === 'navigate') return true;
  return false;
}

Origin / Referer 头校验：对于有 Origin 头的请求，验证其值是否在白名单内。这种方法无需 Token 存储，开销几乎为零。

组合策略实践：生产环境推荐 SameSite Cookie 作为基础防护层，对安全等级更高的操作（如支付、转账）叠加 Token 验证。这样大部分普通请求的 CSRF 防护零开销，仅关键路径承担 Token 成本。

性能监控指标

生产环境需关注以下 CSRF 相关指标：

• Token 生成耗时：P99 应 <5ms，超出则检查 CSPRNG 实现
• Token 验证耗时：含存储访问时 P99 应 <10ms，HMAC 模式应 <0.5ms
• 缓存命中率：本地缓存命中率 >90% 为健康，低于 70% 需扩大缓存容量
• 会话加载频率：对比总请求数与 CSRF 校验请求数，比值过高说明延迟加载未生效

Token 长度与安全性的平衡

配置	长度	熵	性能	适用场景
minimal	16 字节	64 bit	最优	性能敏感、已有其他防护层
balanced	32 字节	128 bit	良好	通用场景（推荐）
secure	64 字节	256 bit	可接受	安全等级最高的场景

128 bit 熵（32 字节 hex）是绝大多数场景的最佳选择——碰撞概率可忽略，性能影响极小。

追问：CSRF 防护和 CORS 是什么关系？

CSRF 和 CORS 解决的是不同层面的跨域问题。CORS 控制的是浏览器是否允许读取跨域响应，CSRF 控制的是浏览器是否自动携带凭据发起跨域请求。一个请求可能被 CORS 阻止但仍然构成 CSRF 风险（如 form 表单提交不受 CORS 约束）。SameSite Cookie 同时减少了 CSRF 和 CORS 的攻击面，但不互为替代。正确做法是同时配置 CORS 白名单和 CSRF 防护，两者互补而非互斥。