SPA安全警示：OAuth2.0致命漏洞

OAuth2.0在SPA应用中的安全陷阱

SPA（单页应用）通常采用隐式授权（Implicit Flow）或PKCE（Proof Key for Code Exchange）授权模式，但存在以下安全隐患：

隐式授权模式的漏洞

• 访问令牌直接暴露在URL中，可能被浏览器历史记录或第三方插件截获。
• 缺乏刷新令牌机制，导致长期会话管理困难。

PKCE模式的潜在风险

• 若未正确实现code_verifier和code_challenge的绑定，可能遭受授权码拦截攻击。
• 前端代码可能被篡改，导致重定向URI被恶意修改。

规避安全陷阱的关键措施

使用PKCE代替隐式授权

• 强制要求SPA应用使用PKCE增强的授权码模式（OAuth2.0 RFC 7636）。
• 示例生成code_verifier的代码：

function generateCodeVerifier() {
  const array = new Uint32Array(32);
  window.crypto.getRandomValues(array);
  return Array.from(array, dec => ('0' + dec.toString(16)).slice(-2)).join('');
}

严格限制令牌存储方式

• 避免使用localStorage存储令牌，改用HttpOnly和Secure标记的Cookie。
• 实现短期令牌自动续期机制，减少令牌泄露窗口期。

强化重定向URI验证

• 在服务端完整验证重定向URI，包括协议、域名和路径。
• 禁止使用通配符域名或开放重定向器。

添加安全头部保护

• 部署CSP（内容安全策略）防止XSS攻击：

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'

• 启用X-Frame-Options和Strict-Transport-Security头部。

实施额外防护层

令牌绑定技术

• 将颁发的访问令牌与前端生成的指纹（如浏览器特性）绑定。
• 每次API请求时验证令牌与客户端的匹配性。

实时令牌吊销

• 实现令牌状态检查端点，对异常IP或设备发起的使用请求立即废止令牌。
• 记录令牌使用日志，建立异常行为检测模型。

开发环境特殊处理

• 联调阶段使用localhost环回地址代替IP直连，避免证书警告导致安全机制失效。
• 为测试环境配置独立的应用注册信息，与生产环境完全隔离。