Token的安全怎么保护？｜阿里巴巴后端开发面经解析

60 秒回答模板

Token 安全我会按全生命周期保护：第一，传输层必须使用 HTTPS，避免 Token 在链路中被窃听或篡改；第二，存储层要根据前端形态选择方案，浏览器端更推荐把敏感 Token 放在 HttpOnly、Secure、SameSite Cookie 中，减少 XSS 读取风险，同时配合 CSRF 防护；第三，签发时控制 Token 的 audience、scope、过期时间和签名算法，避免一个 Token 到处可用或权限过大；第四，使用时做服务端校验、重放防护、设备或会话绑定，关键操作可二次校验；第五，续期时使用短 Access Token 加 Refresh Token，并做 Refresh Token Rotation，一旦发现旧 Refresh Token 被复用就撤销整条会话链；第六，退出登录、改密、风控命中时要支持撤销和黑名单；第七，日志、监控、错误信息、URL 参数都不能暴露 Token，要做脱敏和最小化记录。

考点 传输保护

主线 存储选择

易错点 只回答使用 HTTPS，而忽略浏览器存储、XSS、CS…

深入解析

传输保护

Token 必须只通过 HTTPS 传输，避免明文 HTTP、混合内容、弱 TLS 配置导致中间人窃听或篡改。服务端应开启 HSTS，防止用户被降级到 HTTP；客户端不要把 Token 放在 URL 查询参数里，因为 URL 容易进入浏览器历史、代理日志、Referer、网关访问日志和监控系统。

存储选择

浏览器应用要重点权衡 XSS 和 CSRF。localStorage、sessionStorage 使用方便，但一旦发生 XSS，攻击脚本可以直接读取 Token；HttpOnly Cookie 不能被 JavaScript 读取，能显著降低 Token 被 XSS 直接窃取的概率，但 Cookie 会自动携带，因此要配合 SameSite、CSRF Token、Origin 或 Referer 校验。

Cookie 属性

使用 Cookie 承载敏感 Token 时，应设置 HttpOnly 防止脚本读取，设置 Secure 保证只在 HTTPS 下发送，设置 SameSite=Lax 或 Strict 降低跨站请求自动携带 Cookie 的风险；如果业务必须跨站使用 SameSite=None，则必须同时使用 Secure，并额外加强 CSRF 校验和来源校验。Cookie 还应限制 Domain 和 Path。

签发边界

Token 签发时要设置合理的过期时间、签发方、受众 audience、权限 scope 和用户身份标识。服务端校验时不能只解析 Payload，还必须验证签名、过期时间、issuer、audience、算法白名单等字段。权限应遵循最小权限原则，避免把高权限、长期有效、全系统通用的 Token 发给普通客户端。

续期机制

常见做法是 Access Token 短有效期，Refresh Token 较长有效期但保护更严格。Refresh Token 每次使用后应轮换生成新的 Token，旧的立即失效；如果旧 Refresh Token 再次出现，说明可能被盗用，应撤销该用户当前设备或会话链路。这样即使 Access Token 泄露，攻击窗口也比较短。

撤销能力

完全无状态的 JWT 很难做到即时失效，因此对退出登录、修改密码、封禁账号、权限变更、风控命中等场景，需要引入服务端状态，例如 Token 版本号、会话表、黑名单、Refresh Token 记录或短期缓存。认证可以尽量无状态，但安全事件处理必须有撤销能力。

重放防护

Token 一旦被复制，攻击者可能直接重放请求。防护方式包括短有效期、TLS、关键接口使用 nonce 或时间戳、幂等请求签名、Refresh Token 轮换、设备指纹或会话绑定、异常 IP 和设备风控。设备绑定不能作为唯一安全依据，但可以作为风险识别信号。

日志治理

Token 不能出现在业务日志、异常堆栈、埋点、前端控制台、访问日志、链路追踪、告警通知和第三方分析工具中。网关、应用和客户端都应做脱敏，只保留 Token 摘要、前后少量字符或哈希标识用于排查。代码评审和安全扫描也要检查是否把 Token 写进 URL、日志、配置文件或错误响应。

易错点

只回答使用 HTTPS，而忽略浏览器存储、XSS、CSRF、续期和撤销机制。
把 JWT 签名理解成加密，认为签名后 Payload 就不会被看到。
把 Token 放在 URL 参数中，导致浏览器历史、Referer、访问日志和监控系统泄露。
在 localStorage 长期保存高权限 Token，且没有 XSS 防护、过期时间和刷新机制。
使用 HttpOnly Cookie 后忽略 CSRF，认为脚本读不到 Token 就绝对安全。
没有服务端撤销能力，导致用户退出登录、改密码或账号封禁后 Token 仍可继续访问。
在日志、异常、埋点、链路追踪或告警消息中完整打印 Token。

面试官追问

Token 放在 localStorage 和 Cookie 哪个更安全？

不能简单说哪个绝对安全。localStorage 不会自动随请求携带，CSRF 风险低一些，但 XSS 后脚本能直接读取 Token；HttpOnly Cookie 更抗 Token 窃取型 XSS，但需要 SameSite 和 CSRF 防护。

JWT 有签名，为什么还需要 HTTPS？

JWT 签名主要证明 Token 没有被篡改，不能阻止别人窃听后直接拿去使用。HTTPS 保护传输链路，防止中间人获取 Token。

JWT 如何实现退出登录后立即失效？

纯无状态 JWT 无法天然即时失效。可以把 JWT 有效期设短，并维护服务端状态，例如黑名单、Token 版本号、用户最近改密时间、会话表或 Refresh Token 记录。

Refresh Token Rotation 解决什么问题？

它解决长期 Refresh Token 被盗后难以发现的问题。每次刷新都签发新的 Refresh Token 并使旧的失效，如果旧 Token 再次被使用，就可以判断可能被复制重放。

Token 泄露后应该怎么处理？

应立即撤销相关会话或 Token 版本，清理 Refresh Token，必要时要求用户重新登录或修改密码；同时排查泄露来源，例如 XSS、日志、URL、第三方埋点、代理网关或客户端存储。