SPA中localStorage存储Refresh Token的安全性及Token Rotation防护咨询

Token Rotation（令牌轮换）的复用检测机制，本质是防范同一Refresh Token被多个主体同时使用的场景（比如令牌泄露后被第三方和合法用户同时调用刷新接口），但它解决不了XSS攻击下的核心问题——攻击者能直接窃取到当前有效的Refresh Token，并抢先使用它获取新的合法令牌。

具体场景分析 #

• 当XSS脚本成功注入后，攻击者可以直接读取localStorage中的Refresh Token，立刻调用刷新接口获取新的Access Token和Refresh Token。此时合法用户手中的旧Refresh Token会被标记为失效，但攻击者已经拿到了新的有效令牌，后续可以持续用新的Refresh Token进行轮换，直到攻击被发现。
• 复用检测仅在同一Refresh Token被多次提交时触发，而XSS场景下是攻击者“抢先消耗”了原令牌，不属于复用行为，检测机制无法阻止攻击者获取新的有效凭证。

给安全新手的实践建议 #

• 放弃用localStorage存敏感令牌：SPA场景下，优先用HttpOnly+Secure+SameSite=Strict/Lax的Cookie存储Refresh Token，配合后端CSRF防护（比如在请求头携带CSRF Token）。HttpOnly Cookie无法被JS读取，能从根源切断XSS窃取令牌的路径。
• 缩短Access Token有效期：把24小时的有效期缩至15-30分钟，即使令牌被窃取，攻击者的可用窗口也会大幅缩小。
• 补充即时失效机制：后端维护令牌黑名单，一旦用户主动登出、修改密码或检测到异常行为，立刻将相关令牌加入黑名单，阻止后续使用。
• 强化XSS基础防护：开启CSP（内容安全策略）限制脚本加载源，对所有用户输入做严格的转义过滤，避免恶意脚本注入。
• 采用PKCE授权流程：这是OAuth2专为SPA设计的安全流程，相比隐式流程能有效降低令牌泄露风险，是主流身份服务商推荐的最佳实践。

内容的提问来源于stack exchange，提问作者Henry Peregrino