Spring Security 面试题
本页只放 Spring Security 面试标准回答、项目话术、常见追问和知识点跳转。过滤器链、认证、授权、JWT、CSRF/CORS、数据权限的原理统一放在知识点页。
使用方式
mermaid
flowchart TD
A["面试页:标准回答"] --> B["知识点页:认证授权原理"]
B --> C["项目页:登录、权限、数据安全落地"]高频问题
| 面试题 | 标准回答 | 原理知识点 |
|---|---|---|
| 怎么判断 Spring Security 是否真正学懂 | 不能只会配置登录和 JWT。真正学懂要能从 Servlet Filter、SecurityFilterChain、认证、授权、AuthenticationManager、Provider、UserDetailsService、SecurityContext、Session、JWT、密码哈希、权限模型、数据权限、CSRF/CORS、OAuth2 思路和生产排查一路讲下来,并能说明每个环节为什么这样设计、不这样会出什么安全风险。 | Spring Security从零到精通验收清单 |
| Spring Security 请求链路怎么走 | Tomcat 的 Servlet FilterChain 先调用 DelegatingFilterProxy,后者委托 Spring 容器中的 FilterChainProxy。FilterChainProxy 按顺序选择第一条匹配的 SecurityFilterChain,通过内部虚拟链执行上下文、认证、匿名、异常翻译和授权过滤器;允许后才回到原始链进入 DispatcherServlet。 | 过滤器链全过程、第一条匹配原则 |
| Spring Security 是做什么的 | Spring Security 是 Spring 生态里的安全框架,负责认证、授权、密码加密、会话管理、安全上下文和 Web 安全防护。 | 核心架构 |
| 认证和授权有什么区别 | 认证解决“你是谁”,例如账号密码、Token 登录;授权解决“你能访问什么”,例如角色、权限、数据范围控制。 | 核心架构、权限控制 |
DelegatingFilterProxy、FilterChainProxy、SecurityFilterChain 有什么区别 | DelegatingFilterProxy 是 Servlet 容器中的桥接 Filter;FilterChainProxy 是 Spring 管理的安全总调度器;SecurityFilterChain 由 RequestMatcher 和一组有序安全 Filter 组成。请求通常只执行第一条匹配链,而不是把所有链合并。 | DelegatingFilterProxy、FilterChainProxy |
| 为什么大量逻辑在过滤器链里 | Web 安全必须在 Controller 执行前建立身份和拒绝非法访问。过滤器链统一处理上下文加载、凭证认证、匿名身份、异常翻译、授权和清理;顺序本身属于安全语义,例如认证必须早于最终授权。 | 典型过滤器顺序 |
| 登录流程怎么走 | 用户提交凭证后,认证过滤器构造 Authentication,交给 AuthenticationManager,再由合适的 AuthenticationProvider 调用 UserDetailsService 加载用户并校验密码,成功后写入 SecurityContext。 | 登录认证 |
Authentication 是什么 | 它表示当前认证信息,通常包含用户身份、凭证、权限集合和是否认证成功等状态。 | 核心架构、登录认证 |
AuthenticationManager、Provider、UserDetailsService 的关系 | AuthenticationManager 是认证调度器,AuthenticationProvider 是具体认证执行者,UserDetailsService 负责加载用户、密码密文和权限。 | 登录认证 |
| 为什么密码不能明文存储 | 数据库泄露时明文密码会直接暴露。生产中应使用 PasswordEncoder,例如 BCrypt,对密码做带盐哈希,并通过 matches 校验。密码哈希不是可逆加密。 | 登录认证、加密基础 |
| Session 和 JWT 有什么区别 | Session 登录状态保存在服务端,客户端携带 SessionId;JWT 把身份声明放在签名 Token 中,客户端每次请求携带,服务端解析验证。普通 JWT 通常是签名,不是加密。 | JWT认证、Session与Cookie、JWT签名 |
| JWT 一定比 Session 好吗 | 不一定。JWT 适合前后端分离和分布式入口,但撤销、权限变更实时生效、Token 泄露处理更复杂,常配合 Redis 黑名单或短 Token + 刷新 Token。 | JWT认证 |
| 401 和 403 区别 | 未认证、凭证无效或认证不足时由 AuthenticationEntryPoint 启动认证,API 常返回 401;已真实认证但授权拒绝时由 AccessDeniedHandler 处理,通常返回 403。CSRF 失败也可能是 403,CORS 失败也可能遮住真实状态,不能只按角色排查。 | 异常翻译全过程、401与403 |
| 如何做权限控制 | 常见有 URL 级权限、方法级权限和数据级权限。URL/方法权限解决能不能访问接口,数据权限解决能不能操作这条具体数据。 | 权限控制 |
| 角色和权限码有什么区别 | 角色是权限集合,表示用户身份或岗位;权限码是具体动作能力,例如 asset:create。商业系统通常用角色做授权分组,用权限码做接口和按钮判断,这样角色变化时不用改代码。 | 权限控制 |
为什么只用 @PreAuthorize 不够 | @PreAuthorize 只能判断当前用户是否有某个方法执行权限,不能天然知道这条数据属于哪个医院、部门或租户。商业系统还要在查询条件、业务校验或数据权限拦截器中限制数据范围。 | 权限控制 |
| 数据权限怎么落地 | 常见做法是把用户的数据范围加载到登录态或权限缓存中,查询列表时追加租户、医院、部门、创建人等条件,操作详情时根据资源归属再校验一次,导出和批量操作必须复用同一套规则。 | 权限控制 |
| 权限变更后怎么让缓存和 JWT 生效 | 如果权限放在服务端缓存中,改权限后删除用户权限缓存或发布失效消息;如果权限写进 JWT,旧 Token 在有效期内仍可能携带旧权限,通常要缩短有效期、使用 Token 版本号或 Redis 黑名单。 | 权限控制、JWT认证 |
hasRole 和 hasAuthority 有什么区别 | hasRole('ADMIN') 默认会拼接 ROLE_ 前缀,本质检查 ROLE_ADMIN;hasAuthority('asset:create') 直接检查权限字符串。角色适合粗粒度身份,权限码适合细粒度动作。 | 权限控制 |
| 403 怎么排查 | 先确认用户是否认证成功,再看 Authentication 中是否有需要的权限;然后检查 URL 规则、方法注解、角色前缀、权限缓存是否过期,最后检查业务层数据权限是否把资源拦掉。 | 权限控制 |
| 如何防止水平越权和垂直越权 | 垂直越权靠接口权限和方法权限防止低权限用户调用高危接口;水平越权靠数据权限和资源归属校验,防止用户通过改 ID 操作同级别但不属于自己的数据。 | 权限控制 |
| CSRF 和 CORS 分别是什么 | CSRF 是跨站请求伪造,核心是防止浏览器带着登录态发起非本人意图请求;CORS 是浏览器跨域访问控制,核心是服务端允许哪些来源访问。 | CSRF与CORS |
项目话术
text
在医疗数据采集平台里,Spring Security 主要用于后台用户登录、接口鉴权和数据权限控制。请求进入系统后先过安全过滤器链,解析 Token 并恢复用户身份,再根据角色和权限判断能否访问接口。对医院、科室、数据资产这类资源,还要在业务层做数据范围校验,不能只依赖一个接口权限注解。常见追问
| 追问 | 回答方向 | 跳转 |
|---|---|---|
| 为什么数据权限不能只靠注解 | 说明资源归属、租户、部门、医院范围需要结合业务数据判断。 | 权限控制 |
| 权限改了为什么用户还拥有旧权限 | 说明权限缓存、JWT 快照、网关缓存、本地缓存没有失效。 | 权限控制、JWT认证 |
ROLE_ADMIN 和 admin 为什么匹配不上 | 说明 hasRole 默认拼接 ROLE_ 前缀,hasAuthority 不拼接。 | 权限控制 |
| Token 泄露怎么办 | 说明 HTTPS、短有效期、刷新 Token、Redis 黑名单、设备维度踢下线。 | JWT认证 |
| JWT 为什么不能放敏感信息 | 说明普通 JWT payload 只是 Base64Url 编码,不是加密,别人拿到 Token 可以解码看到内容。 | JWT认证、加密基础 |
| 过滤器顺序错了会怎样 | 说明认证信息未写入、权限判断提前、异常处理不统一等问题。 | 核心架构、过滤器链实战 |
| 前后端分离为什么常禁用 CSRF | 说明不使用 Cookie 会话时 CSRF 风险变化,但仍需防 XSS、Token 泄露和 CORS 放开过大。 | CSRF与CORS |
面试回答模板
text
Spring Security 我会围绕过滤器链回答。请求进入应用后先经过 Security Filter Chain,认证阶段确认用户是谁,成功后把 Authentication 放入 SecurityContext;授权阶段判断用户是否能访问接口。JWT 场景下通常用自定义 Token 过滤器解析身份,接口权限可以用配置或注解控制,数据权限还要在业务层结合资源归属二次判断。深度验收跳转
如果面试官继续追问原理,不要停留在标准回答。按 Spring Security 从零到精通验收清单 回到知识点页,把过滤器链顺序、认证对象流转、SecurityContext、Session/JWT 取舍、密码哈希、数据权限和生产排查讲完整。
本章小结
Spring Security 面试页负责让你会回答。过滤器链为什么能拦截请求、认证对象如何流转、JWT 为什么需要撤销策略、数据权限为什么要落到业务层,都要进入知识点页理解。
