spring boot 用 redis 做会话管理本身不自动带来安全性，关键取决于是否关闭默认“裸连”模式：必须启用 ssl/tls、配置密码认证、隔离命名空间、主动失效会话，缺一不可。
Spring Boot 用 Redis 做会话管理本身不自动带来安全性，关键取决于你是否关掉了默认的“裸连”模式。不设密码、不启加密、不限访问源，等于把 session ID 当成明信片寄出去——谁截获谁登录。
spring-session-data-redis 默认不加密，必须显式配置 SSL/TLS
Spring Boot 内置的 spring-session-data-redis 默认走的是明文 TCP 连接，哪怕你配了 spring.redis.host 和 spring.redis.port，只要没开 SSL，所有 session 数据（包括用户 ID、角色、token 等）都在网络中裸奔。
- 必须在
application.yml中启用 Lettuce 的 SSL：spring.redis.lettuce.ssl=true - 同时指定信任库：
spring.redis.lettuce.ssl-trust-store=classpath:truststore.jks（不是 key-store） - 若 Redis 服务端强制双向认证，还需配
ssl-key-store和对应密码 - 注意：Jedis 不支持 Redis TLS，Lettuce 是唯一可选客户端
密码认证不是可选项，而是连接建立前提
Redis 默认关闭密码验证，spring.redis.password 配置只在客户端发起 AUTH 命令时生效。如果 Redis 服务端没设 requirepass，这个配置就形同虚设。
- 服务端必须在
redis.conf中设置：requirepass your_strong_password - 客户端配置要匹配：
spring.redis.password=your_strong_password - 多数据源场景下，每个
RedisConnectionFactory实例都需单独绑定密码，不能复用未设密码的 factory - 密码不能硬编码在配置文件里，应通过环境变量或 Spring Cloud Config 注入，避免泄露到 Git 或日志
会话 Key 命名空间隔离防越权读写
默认情况下，spring:session: 前缀全局共享。如果你的项目混用了多个 Spring Boot 子系统（如 admin / api / portal），且共用一个 Redis 实例，它们的 session 会互相覆盖或误删。
- 为每个应用配置独立命名空间：
spring.session.redis.namespace=app:admin:sessions - 配合 Redis ACL 使用时，确保该用户只能访问对应前缀的 key：
~app:admin:sessions:* - 不要依赖默认的
spring:session:，它在多租户或灰度发布中极易引发会话污染
会话超时与主动失效必须双保险
仅靠 Redis 的 TTL（如 spring.session.timeout=1800）不够。用户登出、密码变更、权限回收等场景，必须主动删除 session，否则攻击者仍可用旧 cookie 维持登录。
- 登出时调用：
sessionRepository.deleteById(sessionId)（SessionRepository是自动注入的 bean） - 敏感操作后清空同用户所有 session：
sessionRepository.findByPrincipalName(username).forEach(s -> sessionRepository.deleteById(s.getId())) - 避免用
HttpSession.invalidate()，它只清除当前请求的 session 引用，不触发 Redis 删除
真正难的不是配置那几行 YAML，而是让每个环节都拒绝“默认即安全”的假设——SSL 要开、密码要设、命名空间要分、失效要主动。漏掉任意一环，session 就可能变成攻击者的跳板。
