1. 先理清整个安全链条1.1 登录到退出全程有哪些安全风险点做 Java Web 开发的朋友应该都有过这种感觉功能通了心里却总觉得不踏实。尤其是涉及登录、会话、退出这一整条链路每个环节都有坑等着你踩。拿一个典型的用户请求来说用户输入账号密码提交登录请求服务端校验通过后创建会话然后在后续每次访问时带着会话凭证直到用户点击退出或者会话过期。这中间有任何一步处理不当都可能让整个系统的安全性崩塌。先列一下这条链路里最常见的风险点。登录阶段密码明文存储、口令爆破、用户名枚举、登录接口被刷、验证码逻辑绕过。会话阶段会话固定、会话劫持、Cookie 未设置 HttpOnly 导致 XSS 直接偷走令牌、Session 超时设置不合理。请求阶段SQL 注入、CSRF 跨站请求伪造、越权访问、敏感数据未做权限校验。退出阶段退出接口只处理了前端跳转、服务端 Session 没有销毁、Cookie 没有清除、token 没有加入黑名单。这些风险单独看可能觉得“没那么容易中招”但组合起来就是真实的安全事故。我还想强调一点安全问题不能只停留在“能用”的层面。很多团队在开发时以“功能完成”为标准安全只是顺手做一下等上线后被扫描工具打出一堆高危漏洞才着急。真正靠谱的做法是在设计阶段就把登录到退出当作一条完整的信任链路来对待每一步都明确“谁来、凭证是什么、如何校验、如何失效”。1.2 技术选型如何影响安全策略Java Web 的安全实现方式有很多种常见的组合有纯 Servlet Filter、Spring MVC 拦截器、Spring Security OAuth2、Spring Boot Sa-Token 等。选型不同安全策略的落点也会不一样。但无论用哪种框架底层的安全原则是相通的。如果你用的是原生 Servlet 和 Filter那所有安全控制都得自己写登录状态校验、权限拦截、Session 管理、CSRF Token 生成与校验。优点是可控性强能看清每一步在做什么缺点是容易遗漏毕竟很多细节只有踩过坑才知道。如果你用 Spring Security框架已经帮你封装了认证过滤器链、Session 管理、CSRF 防护、密码加密等能力开箱即用。但封装的另一面是黑盒效应很多人配了一堆规则却不理解为什么这么配出了问题也不知道从哪排查。所以我不建议一上来就无脑引入框架而是先理解核心的认证流程再借框架去落地。还有个容易被忽略的点前后端分离架构下的安全策略与传统服务端渲染完全不同。传统场景下Session 与 Cookie 天然配合由服务端维护用户状态前后端分离后很多团队改用 Token 方案服务端不再保存会话而由客户端持有凭证。这看起来简单但引入的问题也不少比如 Token 续期、登出失效、CSRF 边界变化、XSS 对 Token 的窃取风险等。所以我在下文里会把两种模式下各自要注意的关键点都拿出来说一遍避免大家拿着传统方案套前后端分离项目。2. 登录环节的安全设计2.1 密码存储哈希的选用不能偷懒登录安全的第一步是密码存储。我见过不少项目在数据库里直接存明文密码理由是“内网系统问题不大”。这种想法基本等于把门锁卸了然后在门口贴一张“请勿入内”。内网系统一旦被横向渗透所有密码直接裸奔用户在其他平台的密码也会跟着遭殃。正确的做法是对密码进行单向哈希再加盐存储。注意几个关键词单向、哈希、加盐。单向意味着无法从哈希值反推原始密码哈希意味着相同输入能得到固定长度输出加盐则是为了对抗彩虹表攻击给每个用户生成一个随机盐值让相同密码在不同用户下产生不同哈希。具体选型上MD5 和 SHA-1 已经不适合用于密码存储原因很简单计算速度快暴力破解成本低。推荐使用 BCrypt、SCrypt 或 Argon2 这类专门为密码设计的慢速哈希算法。以 BCrypt 为例Spring Security 里直接注入 BCryptPasswordEncoder 就能用。每次加密时算法会自动生成随机盐并将盐一起编码进结果字符串你不需要单独建 salt 字段校验时直接 matches 方法比对即可。// 注册生成密码哈希 BCryptPasswordEncoder encoder new BCryptPasswordEncoder(); String hashedPassword encoder.encode(rawPassword); // 登录校验比对原始密码与哈希值 boolean matches encoder.matches(rawPassword, storedHashedPassword);我建议把哈希强度strength也调高一些默认 10 可以适当调整到 12 或更高。强度越高计算越慢对合法用户只是毫秒级延迟但攻击者批量跑字典的代价会成倍增加。生产环境选 12 左右比较平衡太高了在低配服务器上并发登录时会明显拖慢性能。2.2 登录验证中的防爆破机制登录接口天然是攻击者的重点目标。没有防护的登录接口就像没有门卫的大楼任何人可以无限次尝试密码。常见的防爆破手段有几种验证码、IP 限流、账号锁定、渐进式延迟。验证码需要特别注意一个逻辑漏洞很多系统的验证码只在前端校验服务端拿到请求后只验证用户名密码不再检查验证码。这种情况下攻击者直接用脚本模拟登录请求完全绕过了前端验证码。正确做法是服务端生成验证码并把答案存在 Session 或 Redis 中登录请求到达时先校验验证码再校验账号密码。账号锁定方案也需要考虑业务影响连续失败 5 次锁定账号 5 分钟听起来合理但攻击者可以故意批量输错密码导致正常用户账号被锁造成变相拒绝服务。所以更稳妥的做法是结合 IP 维度做限流比如同一 IP 每分钟最多允许 10 次登录尝试账号维度则采用渐进式延迟比如失败次数越多下次允许尝试的时间间隔越长。渐进式延迟不会完全锁定账号但对暴力破解有显著抑制作用。实现层面推荐把失败次数和锁定状态放在 Redis 里因为单机 Session 在集群环境下无法共享而且重启会被清掉。用 Redis 的 INCR 和 EXPIRE 可以轻松实现计数和时间窗口String failKey login:fail:user: username; Long count redisTemplate.opsForValue().increment(failKey); if (count 1) { redisTemplate.expire(failKey, Duration.ofMinutes(10)); } if (count 5) { // 返回尝试次数过多请稍后再试 }这里还有一个小细节提示信息要尽量模糊避免明确返回“用户不存在”或“密码错误”。否则攻击者可以通过响应差异枚举有效用户名。统一返回“用户名或密码错误”是行业共识。2.3 登录成功后的令牌生成登录成功后服务端需要给用户一个凭证后续请求携带这个凭证证明身份。凭证的生成方式直接决定了整个会话的安全性。最传统的方式是生成一个随机 Session ID存到服务端 Session 中通过 Set-Cookie 下发给浏览器。这种方式胜在简单服务端可以随时销毁会话。但要特别注意 Session ID 必须是高强度的随机数不能是自增 ID、时间戳、用户名的简单拼接。Java 原生的UUID.randomUUID()随机性一般但也可以更推荐使用 SecureRandom 生成 128 位以上随机值。String token new BigInteger(160, new SecureRandom()).toString(36);如果采用 JWT 这类无状态 Token登录成功后生成一段包含用户信息和过期时间的签名令牌服务端不保存状态。前后端分离场景用这种方式比较多但也带来一个麻烦退出时无法真正让旧 Token 立即失效只能等它自然过期。如果你的项目对“退出后 Token 必须立刻失效”有强要求建议引入 Token 黑名单机制把退出的 Token 标识存到 Redis 里校验时判断一下是否在名单中。这个方案兼顾了无状态和可控性。![附图说明令牌生成部分不涉及图表仅记录要点。]我个人的经验是内部管理系统优先选 Session Cookie简单可靠、退出彻底对外开放的互联网应用如果团队对安全有较强把控力再考虑无状态 Token。千万不要因为“前后端分离就必须用 JWT”这种认知选择技术方案安全设计永远从实际约束出发。3. 会话保持与请求防护3.1 Session 与 Cookie 的配置细节会话建立以后紧接着要处理的是会话凭证的保存和传输。Java Web 中默认通过 Cookie 中的 JSESSIONID 传递 Session ID这里有不少配置细节直接关系到安全性。第一Cookie 必须加 HttpOnly 属性。这个属性表示浏览器端 JavaScript 无法读取该 Cookie即使页面被注入了恶意脚本也没办法把 JSESSIONID 偷走。在 Spring Boot 中设置很简单server.servlet.session.cookie.http-onlytrue server.servlet.session.cookie.securetrue server.servlet.session.cookie.same-sitelax第二Secure 属性。这个属性要求 Cookie 只能通过 HTTPS 传输。如果站点已经全站 HTTPS务必开启。否则在 HTTP 明文中传输的 Session ID 会被中间人截获直接导致会话劫持。第三SameSite 属性。这个属性是用来缓解 CSRF 的。设为 Lax 时跨站请求不会携带 Cookie大多数业务场景下影响不大安全性却提升明显。如果面对的是对安全性要求更高的后台系统可以设成 Strict但要注意用户从第三方链接进入站点时可能登录状态不生效需要重新登录。Session 还有一个有效期问题需要重点设计。有效期太短用户操作频繁被踢体验差有效期太长风险窗口也变大。合理的做法是设置两种超时固定超时和空闲超时。固定超时比如 8 小时强制失效空闲超时比如 30 分钟无操作自动失效。Spring Boot 中空闲超时可以通过server.servlet.session.timeout30m配置固定超时则需要在业务代码中记录登录时间并在每次请求时检查。对于集群部署Session 默认是存在单台节点内存中的。负载均衡把请求分发到不同节点时Session 可能丢失。解决办法是引入 Spring Session 并存在 Redis 中这样所有节点共享同一份会话数据同时也能统一做会话失效管理。这里要顺带提示用 Redis 存 Session 后Session ID 的安全属性依然有效Cookie 的配置也照旧不要因为换了存储就忽视传输安全。3.2 CSRF 与 XSS 防护CSRF 和 XSS 是 Web 安全里经常同时出现的一对难兄难弟但它们本质不同。CSRF 是攻击者利用用户的登录态诱导用户在不知情的情况下发起恶意请求XSS 是攻击者向页面注入脚本窃取用户数据或冒充用户操作。先讲 CSRF。核心防护思路是让服务端能够区分“正常请求”和“被伪造的请求”。常用手段有三种校验 Referer 字段、在表单中嵌入 CSRF Token、利用 SameSite Cookie 属性。Referer 校验容易被隐私设置影响有时候拿不到SameSite 属性兼容性逐渐变好CSRF Token 是最通用的方案。CSRF Token 的流程是服务端生成一个随机 Token 存在 Session 中在页面渲染时放入隐藏表单字段提交请求时服务端比对请求中的 Token 与 Session 中的 Token 是否一致。为什么这招有效因为攻击者在伪造请求时没法获知当前用户 Session 里的 Token 值。input typehidden name_csrf_token value${sessionScope.csrfToken} /注意一个细节对登录接口和退出接口也要做 CSRF 防护不能只盯着业务接口。因为登录接口伪造一个别人账号的登录请求、退出接口把用户会话踢下线这些都会造成实际危害。曾经有专门针对注销接口的攻击持续向用户浏览器发送带第三方域 Referer 的注销请求迫使用户反复退出体验极差防护之后这类骚扰就少了。再讲 XSS。防护思路是“所有用户输入都不可信”。输出到 HTML 时做编码输出到 JavaScript 时做转义输出到 URL 时做白名单校验。Java 中常见的工具是 ESAPI 或 OWASP Java Encoder。Spring Boot 项目中也可以在全局做一些预处理比如定义一个过滤器对常见的script、javascript:等关键字进行拦截。不过我更想强调的是XSS 防护的重点不在过滤而在输出编码。过滤是黑名单思维总有绕过方式编码是白名单思维把所有动态内容当作纯文本输出浏览器才不会执行。把这条原则记牢XSS 防护就有基本盘了。3.3 SQL 注入和权限越权的拦截思路登录接口、查询接口都容易受到 SQL 注入攻击。攻击者在用户名、密码等输入框里拼接 SQL 片段试图绕过校验或获取额外数据。比如经典的万能密码 OR 11Java 中对 SQL 注入最有效的防护是预编译语句。使用PreparedStatement时SQL 结构和参数是分离的参数不会被当作 SQL 执行。MyBatis 中则是强调用#{}占位符而不是${}。${}是字符串拼接存在注入风险一般只用于动态表名、排序字段等场景而且要严格校验白名单。!-- 安全写法 -- select idfindUser resultTypeUser SELECT * FROM user WHERE username #{username} AND password #{password} /select !-- 危险写法严禁用于入参直接拼接 -- select idfindUser resultTypeUser SELECT * FROM user WHERE username ${username} /select比起 SQL 注入越权漏洞在业务系统中更隐蔽也更常见。水平越权指普通用户访问同级别其他用户的数据比如修改订单、查看他人信息垂直越权指低权限用户执行高权限操作比如普通员工访问管理员接口。这类漏洞 IDE 不会帮你发现代码扫描工具也容易漏掉需要靠仔细的业务逻辑审计和接口测试。我常用的检查方法是每个接口在拿到请求参数时先问三个问题——当前登录用户是谁他是否有权限执行这个操作传入的资源 ID 是否属于这个用户把这三个问题落实到代码里能挡住大部分越权攻击。GetMapping(/order/{id}) public Order getOrder(PathVariable Long id) { Long currentUserId SecurityUtils.getCurrentUserId(); Order order orderService.getOrder(id); if (!order.getUserId().equals(currentUserId)) { throw new BusinessException(无权访问该订单); } return order; }4. 退出登录的安全性实现4.1 后端会话销毁的正确方式很多人觉得退出登录就是把前端页面跳回登录页这是完全错误的理解。退出登录的核心动作必须在服务端完成销毁会话状态。传统 Session 模式下正确处理是获取当前 Session调用invalidate()方法并清除 Cookie。Servlet 里有标准的写法PostMapping(/logout) public Result logout(HttpServletRequest request, HttpServletResponse response) { HttpSession session request.getSession(false); if (session ! null) { session.invalidate(); } Cookie cookie new Cookie(JSESSIONID, null); cookie.setMaxAge(0); cookie.setPath(/); response.addCookie(cookie); return Result.success(); }这里有个常见误区request.getSession()不带参数时如果当前没有会话会创建一个新会话。退出接口如果用了这个写法反而会“制造”一个新会话。正确做法是传false没有会话就直接跳过销毁逻辑。另外要注意 Cookie 的清除参数。新建 Cookie 时必须保证Path与原 Cookie 一致否则浏览器不会覆盖它导致旧 Cookie 仍然有效。如果应用部署在/api前缀下Path 也要写成/api。这个细节经常被遗漏我在排查问题时就见过好几次“退出登录后再次访问还是会带上旧会话”的情况原因就是 Path 不匹配。对于无状态 Token 模式后端需要把 Token 标记为失效。最直接的方案是 Redis 黑名单退出时把 Token 的 jti 或签名存进 Redis设置过期时间为 Token 剩余的有效期。后续请求在过滤器里校验黑名单存在则拒绝。4.2 前端 Cookie 和本地状态清理后端完成会话销毁后前端也要配合清理。浏览器里保存的会话凭证不清理的话虽然服务端已失效但本地残留可能引起奇怪的问题。最典型的是用户退出后手工登录另一个账号浏览器自动带上两个 Cookie 的历史痕迹影响调试和体验。对服务端渲染项目推荐在退出接口响应里用Set-Cookie清除 JSESSIONID前端不需要额外处理。对前后端分离项目如果 Token 存在localStorage或sessionStorage中退出时必须移除。这里提醒一句Token 存在 localStorage 里其实有 XSS 风险因为任何脚本都能读取它。更安全的是放在内存变量中或者使用 HttpOnly Cookie 存储。当然HttpOnly Cookie 存储 Token 时需要处理 CSRF也就是我们前面提到的 SameSite 和 Token 双重策略。前端清除逻辑还应该考虑“会话状态”的同步。比如 Vue 或 React 项目通常在全局状态管理里存一份登录态标识退出后这块状态必须同步清掉否则页面部分组件还显示用户名给人一种退出不彻底的错觉。我见过团队只清了 localStorage忘记清 Pinia 或 Redux 里的全局状态结果用户重新登录后页面却显示着上一个账号的昵称这种低级事故屡次发生。4.3 多点登录与单点登出的处理多点登录是日常开发里逃不开的话题。有的业务允许同一个账号在多个设备同时登录有的业务则要求同一账号只能在一个设备登录后者在多设备场景下处理起来更复杂。先看“同账号只能同时登录一个设备”的实现思路。登录时把新生成的会话或 Token 绑定到账号维度存进 Redis比如 key 为login:token:user:123value 为新 Token。同时旧 Token 被覆盖通过旧 Token 访问接口时校验失败。用 JWT 时实现思路是每次请求都拿 Token 去 Redis 查一下当前有效 Token 是否等于请求中的 Token不等就返回请重新登录。再看“一个账号多个设备同时登录”的场景。这时通常需要支持单点登出也就是在任意一台设备上退出其他所有设备的会话都失效。实现方式是维护一个账号对应的会话集合退出时遍历销毁。用 Redis 时key 用login:sessions:user:123value 是一个 Set存放所有有效的 Token 或 Session ID。退出时从这个 Set 里清掉对应 Token并发给其他设备一个强制下线信号。如果技术栈允许可以通过 WebSocket 推送一个“账号已在其他设备登录”的事件让前端主动跳转登录页。单点登出的设计里最容易被忽略的是被动下线的体验。用户可能正在填写一个很长的表单结果因为其他设备登录被迫下线数据全丢了。比较好的做法是服务端标记会话失效但前端不立即销毁页面状态等下一次接口请求收到 401 时把当前页面数据暂存到本地再引导用户重新登录并恢复数据。这个细节属于体验优化范畴但做好了能大幅降低用户的抵触情绪。5. 实战中踩过的坑和排查方法5.1 常见问题速查把我在实际项目中遇到的高频问题整理成速查表方便大家对照排查现象可能原因排查思路退出后按浏览器后退键还能看到上一页面数据页面走了本地缓存或浏览器 BFCache排查是否有禁止缓存响应头页面退出后强制刷新路由状态退出后再次访问仍处于登录态服务端会话未销毁或 Cookie Path 不匹配抓包看退出响应是否真的清除了 Cookie检查 Set-Cookie 的 Path登录后跨越部署节点时掉线集群模式下 Session 未共享引入 Redis 存 Session确认 Cookie 名称在各节点一致用户反馈在公共 WiFi 上账号被盗登录未强制 HTTPSSession ID 明文传输开启全站 HTTPSCookie 添加 Secure 属性被安全扫描报 CSRF 漏洞未启用带随机 Token 的校验机制启动 CSRF Token 校验关键接口逐一排查接口返回 JSON 中泄露用户手机号对象序列化时未做脱敏统一返回值封装敏感字段加脱敏注解黑名单用户在退出 API 反复刷新触发告警注销接口无防刷给退出接口加频控限制和登录接口同等对待还有一个非常隐蔽的问题会话超时时间在多个地方同时配置。比如 Spring Boot 的server.servlet.session.timeout、web.xml 中的session-timeout、纯代码session.setMaxInactiveInterval()都设置了不同值最终的生效结果可能和预期不一致。遇到超时行为异常时先统一配置源。5.2 安全测试清单每次上线前建议按照这个清单过一遍登录到退出链路密码存储数据库中看不到明文密码哈希算法是 BCrypt 或更强。登录接口连续错误尝试有渐进式延迟或验证码响应信息不区分“用户不存在”和“密码错误”。会话凭证Session ID 随机性强Cookie 设置了 HttpOnly、Secure、SameSite。登录状态校验未登录访问受保护资源返回 401 或重定向到登录页。CSRF关键表单提交、退出接口都校验了 CSRF Token。越权登录用户 A 无法访问用户 B 的资源。SQL 注入所有 SQL 使用预编译占位符没有${}拼接入参。XSS用户输入的内容在输出时正确编码。退出服务端会话销毁Cookie 清除Token 黑名单生效。会话过期过期后访问旧接口无法通过校验且前端按预期跳转到登录页。这十条看起来简单但每一条背后都有对应的代码实现。如果审计时发现哪一条答不上来建议先补上再上线。安全不是一次性的工作每次功能迭代都可能引入新的风险点所以这个清单也应该作为回归测试的一部分长期保留。我在实际排查安全问题时的体会是绝大多数漏洞不是技术上做不到而是开发时没有把安全当作硬性需求来对待。把“从登录到退出”这条链路的安全设计前置到编码阶段每写一个接口都问一遍权限校验和凭证管理是否到位比事后修补省太多事。以后再接到安全相关的任务不妨先从这张链路图开始梳理把每一步的凭证流转、失效时机、传输通道都画清楚再动手写代码效果会好很多。