# Petclinic 安全改造：Basic Auth 与角色授权实战

```text
旧方案：自己写 Interceptor 判断 Token → 冲突：绕过 Spring Security Filter Chain → 后果：CSRF、Session、安全 Header 全部失效
```

Petclinic 已经内置了可开关的 Basic Authentication 和 OWNER_ADMIN、VET_ADMIN、ADMIN 角色模型。

我是老李，今天不重新发明安全框架，而是直接打开 Petclinic 已有的安全开关，观察 Spring Security Filter Chain 与 Spring MVC DispatcherSer

vlet 的前后关系。

为什么自己写 Interceptor 判断 Token 是错误方案？

应该选择 Basic Auth 还是继续用自定义 Token 校验？

选错之后会不会导致 401 和 403 语义混乱，甚至安全 Header 全部丢失？

# 01、故事

```text
14:30 → 深圳南山工位 → 任务：给 Owner API 加角色限制 → 冲突：前端催着要权限矩阵，后端搜不到现成配置
```

下午两点半，深圳南山科技园工位，空调吹得屏幕发凉。任务是给 Petclinic 的 Owner API 加上角色限制，只允许 OWNER_ADMIN 访问。

前端同事在群里催权限矩阵，说下午联调。我打开 Petclinic 源码，搜了半天没找到自己熟悉的 SecurityConfig 写法。

仓库里只有几个 properties 开关，没有显式的 Filter Chain 配置。我有点慌，担心直接改会破坏现有登录流程。

> 南山午后雨未停，
> 权限矩阵催不停。
> 源码翻遍无头绪，
> 开关背后藏玄机。

# 02、问题

```text
需求变化：Owner API 要按角色隔离 → 冲突：Petclinic 默认只开 Basic Auth，没有细粒度授权 → 后果：Vet 用户也能访问 Owner 接口
```

Petclinic 默认只开启了 Basic Auth，所有认证用户都能访问大部分接口。需求变化后，Owner、Vet、User 三类 API 需要分别限制角色。

如果只开 Basic Auth 而不配置角色授权，VET_ADMIN 也能访问 Owner 接口，造成越权。

更糟的是，自己写 Interceptor 判断 Token 会绕过 Spring Security 的 Filter Chain。

可验证的验收标准是：用 Postman 分别携带不同角色凭证，Owner API 对非 OWNER_ADMIN 返回 403，未认证返回 401。

> 开关一开万事通，
> 角色未分权限空。
> 越权访问无人管，
> 自写拦截更成空。

# 03、原理

```text
Browser → Filter Chain → DispatcherServlet → Controller
```

Spring Security 的核心是一组 Filter，它们运行在 Servlet 容器与 DispatcherServlet 之间。

Basic Authentication 由 BasicAuthenticationFilter 处理，角色授权由 AuthorizationFilter 处理。

请求先经过 Filter Chain，认证和授权通过后才进入 DispatcherServlet。

反直觉的是：你在 Interceptor 里判断 Token，请求其实已经穿过了整个 Filter Chain，安全 Header 和 CSRF 保护早已失效。

另一个反直觉判断：403 不是认证失败，而是认证成功但权限不足。很多人把 401 和 403 混为一谈，导致前端无法区分“未登录”和“没权限”。

> Filter 在前拦请求，
> Servlet 在后管路由。
> 认证授权先过关，
> 拦截器里已太迟。

# 04、架构

```text
HTTP 请求 → Security Filter Chain → DispatcherServlet → Controller → 响应
```

安全层位于 Servlet 容器与 Spring MVC 之间，负责认证、授权、CSRF、Session 管理、安全 Header。

本模块的边界是：只处理安全相关逻辑，不涉及业务数据。收益是集中管理安全策略，代价是增加一层 Filter 调用链。

适用条件是所有需要认证和授权的 Web 应用。如果只是静态资源或公开 API，可以关闭部分 Filter。

> 安全层在中间站，
> 认证授权不偷懒。
> 业务逻辑在后头，
> 边界清晰好扩展。

# 05、第一版实战

```text
环境 → 配置 → 代码 → 启动 → 验证 → V1
```

环境：JDK 17、Maven 3.9、Spring Boot 3.x、spring-petclinic-rest 当前版本。

第一步，打开 Basic Auth 开关。在 application.properties 中配置：

```properties
petclinic.security.enable-basic-auth=true
petclinic.security.enable-role-auth=true
```

第二步，确认角色模型。Petclinic 已有 OWNER_ADMIN、VET_ADMIN、ADMIN 三种角色。

第三步，启动应用：

```bash
mvn spring-boot:run
```

第四步，用 Postman 验证。先不带凭证请求 Owner API：

```http
GET /api/owners
```

预期返回 401。再携带 OWNER_ADMIN 凭证：

```http
GET /api/owners
Authorization: Basic base64(owner:owner)
```

预期返回 200。日志示例输出：

```text
示例输出：
2025-01-01 14:35:00.000 INFO  o.s.s.web.FilterChainProxy - Securing GET /api/owners
2025-01-01 14:35:00.010 INFO  o.s.s.web.authentication.www.BasicAuthenticationFilter - Found Basic Authorization header
```

成功标准：未认证返回 401，OWNER_ADMIN 返回 200。

> 开关一开认证起，
> 角色模型已备齐。
> Postman 一测见分晓，
> 401 与 200 各归位。

# 06、排查

```text
诊断树：401 → 认证失败 → 检查凭证；403 → 授权失败 → 检查角色；200 → 权限过宽 → 检查配置
```

问题一：携带正确凭证仍返回 401。怀疑是 Basic Auth 开关未生效。检查配置：

```bash
grep -r "enable-basic-auth" src/main/resources/
```

证据显示配置值为 false，根因是 profile 覆盖了默认配置。修复：在对应 profile 中显式开启。

问题二：VET_ADMIN 能访问 Owner API，返回 200。怀疑角色授权未生效。检查安全配置类：

```bash
grep -r "OWNER_ADMIN" src/main/java/
```

证据显示 Owner API 只配置了 authenticated()，没有 hasRole。修复：改为 hasRole('OWNER_ADMIN')。

**错误尝试：** 我一开始在 Interceptor 里手动判断角色，结果安全 Header 全部丢失，CSRF 保护也失效。

> 排查路上多歧路，
> 凭证角色两相误。
> 证据指向配置处，
> 修复之后路自通。

# 07、优化

```text
V1：只开 Basic Auth → 证据：Vet 用户越权访问 Owner API → V2：按角色限制 API
```

V1 只开启了 Basic Auth，所有认证用户都能访问所有 API。证据是 VET_ADMIN 凭证访问 Owner API 返回 200。

优化方案：在安全配置中按角色限制 API。修改 SecurityConfig：

```java
http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/api/owners/**").hasRole("OWNER_ADMIN")
    .requestMatchers("/api/vets/**").hasRole("VET_ADMIN")
    .requestMatchers("/api/users/**").hasRole("ADMIN")
    .anyRequest().authenticated()
);
```

同时保留 Basic Auth 和 CSRF 配置。重新启动后，VET_ADMIN 访问 Owner API 返回 403。

> 权限矩阵落代码，
> 角色隔离不混杂。
> 越权访问被拦截，
> 403 响应守门闸。

# 08、演进

```text
V2：角色授权 → 能力：401/403 语义清晰 → 遗留：CSRF 与 Session 策略待定
```

V2 实现了角色授权，401 表示未认证，403 表示无权限。用 V1 同一组请求验证：未认证返回 401，VET_ADMIN 访问 Owner API 返回 403。

收益是权限边界清晰，代价是每个 API 都要显式配置角色。适用场景是内部管理系统。

遗留问题是 CSRF 保护对无状态 API 是否必要，Session 策略是否需要调整。

> 演进路上步步高，
> 权限边界已画牢。
> 遗留问题待解决，
> CSRF 与 Session 再推敲。

# 09、洞见

```text
从现象到判断：401 与 403 的语义分离是安全设计的基础
```

## 反直觉判断：Interceptor 判断 Token 是错误方案

```text
请求 → Filter Chain → DispatcherServlet → Interceptor → Controller
```

很多人以为 Interceptor 在 Controller 之前，可以替代安全 Filter。

实际上 Interceptor 在 DispatcherServlet 内部，请求已经穿过了整个 Filter Chain。

安全 Header、CSRF、Session 管理都在 Filter Chain 中完成，Interceptor 里判断 Token 等于把安全大门拆了再在客厅装锁。

## 反直觉判断：403 不是认证失败

```text
401 = 未认证；403 = 已认证但无权限
```

前端需要根据 401 跳转登录页，根据 403 提示无权限。如果混淆两者，用户体验会非常糟糕。

## 安全 Header 是 Filter Chain 的副产品

```text
Security Filter → 响应头注入 → 浏览器执行安全策略
```

X-Content-Type-Options、X-Frame-Options 等 Header 由 Spring Security 自动注入。

绕过 Filter Chain 意味着这些 Header 全部丢失。

## Method Security 是最后一道防线

```text
Controller 方法 → @PreAuthorize → 方法级授权
```

即使 URL 配置遗漏，方法级注解仍能兜底。但 Method Security 不能替代 Filter Chain，两者是互补关系。

> 洞见深处有真知，
> 反直觉处见本质。
> 安全设计无小事，
> 层层防线各司职。

# 10、系统落地

```text
入口：Postman/浏览器 → 服务：Spring Security Filter Chain → 本模块：Basic Auth + 角色授权 → 存储：用户与角色表 → 未实现：OAuth2/JWT
```

原来 Petclinic 只有可开关的 Basic Auth 和角色模型，但没有显式的 API 权限矩阵。

本篇增加了按角色限制 Owner、Vet、User API 的配置，现在能清晰区分 401 和 403。

下一篇缺的是 OAuth2 或 JWT 支持，以及更细粒度的 Method Security 覆盖。官方文档见 Spring Security 文档首页。

> 系统落地靠配置，
> 权限矩阵已落地。
> 下一步向 OAuth2，
> 无状态认证再升级。

# 11、小结

```text
三问三答：为什么自写 Interceptor 错误？选 Basic Auth 还是自定义 Token？选错后果是什么？
```

自写 Interceptor 判断 Token 会绕过 Filter Chain，导致安全 Header、CSRF、Session 全部失效。

当前阶段选择 Basic Auth，因为 Petclinic 已内置且适合内部系统。自定义 Token 应通过 Spring Security 的 Filter 实现，而不是 Interceptor。

选错后果是 401 与 403 语义混乱，安全 Header 丢失，越权访问无法拦截。当前状态：V2 已实现角色授权，401/403 语义清晰。

> 三问三答已分明，
> 安全设计不迷行。
> 当前状态已落地，
> 后续演进再深耕。

# 12、作业

```text
理解 → 实战 → 排障 → 架构判断
```

## 理解题：为什么 Interceptor 不能替代 Spring Security Filter？

因为 Interceptor 在 DispatcherServlet 内部，请求已经穿过了整个 Filter Chain。

安全 Header、CSRF、Session 管理都在 Filter Chain 中完成，Interceptor 里判断 Token 等于绕过安全大门。

## 实战题：用 Postman 验证 Owner API 对 VET_ADMIN 返回 403

启动 Petclinic，开启 Basic Auth 和角色授权。用 VET_ADMIN 凭证请求 /api/owners，确认返回 403。再用未认证请求确认返回 401。

## 排障题：配置了 hasRole 但仍返回 200，如何排查？

检查角色名称是否匹配，Spring Security 的 hasRole 会自动加 ROLE_ 前缀。检查配置是否被其他 profile 覆盖。检查请求是否匹配了更宽松的规则。

## 架构判断题：无状态 API 是否需要 CSRF 保护？

如果 API 完全无状态，不依赖 Cookie 和 Session，可以关闭 CSRF。但如果使用 Basic Auth，浏览器会缓存凭证，仍建议保留 CSRF 或改用 Token 方案。

> 作业四题各不同，
> 理解实战排障中。
> 架构判断需谨慎，
> 安全设计不放松。

# 13、升华

```text
工程结论：安全设计必须走框架主路径，不能自创旁路
```

有依据的结论是：Spring Security 的 Filter Chain 是安全设计的主路径，任何绕过它的方案都会导致安全能力缺失。

Petclinic 已有的 Basic Auth 和角色模型是很好的起点，直接开启并配置权限矩阵比自写安全代码更可靠。

下一篇可以深入 Method Security 和 OAuth2，进一步细化权限控制和无状态认证。

> 安全设计走主路，
> 自创旁路必成误。
> 框架能力善利用，
> 工程实践有归处。

**系列项目：** Petclinic REST API 安全改造

**已完成：** Basic Auth 开关与角色模型

**本篇：** 按角色限制 Owner、Vet、User API，验证 401/403

**下一篇：** Method Security 与 OAuth2 无状态认证

Petclinic 已经内置了可开关的 Basic Authentication 和 OWNER_ADMIN、VET_ADMIN、ADMIN 角色模型。

《SpringMVC7实战》第13招 Web Security不能靠Interceptor

从 Petclinic 已有 Basic Auth 与角色模型出发，验证 Filter Chain 与 DispatcherServlet 前后关系，用 Pos

架构师

编程语言

后端

安全

Petclinic安全改造实战：开启BasicAuth与角色授权，实现OwnerAPI权限隔离。通过SpringSecurity FilterChain配置，清晰区分401未认证与403无权限，避免Interceptor绕过安全机制导致CSRF、安全Header失效。优化角色访问控制，确保VET_ADMIN无法越权访问Owner接口。

代码解释

API安全

容器

路由

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Petclinic安全改造实战：开启BasicAuth与角色授权，实现OwnerAPI权限隔离。通过SpringSecurity FilterChain配置，清晰区分401未认证与403无权限，避免Interceptor绕过安全机制导致CSRF、安全Header失效。优化角色访问控制，确保VET_ADMIN无法越权访问...

《SpringMVC7实战》第13招 Web Security不能靠Interceptor-腾讯云开发者社区-腾讯云

《SpringMVC7实战》第13招 Web Security不能靠Interceptor

《SpringMVC7实战》第13招 Web Security不能靠Interceptor

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐