# Spring Boot 默认安全边界：Petclinic 如何从裸奔到可上线

```text
功能正常 → 默认接口与管理端点开放 → 数据可被匿名篡改 → 无法上线
```

Petclinic 的页面、表单、数据库读写都已经跑通，开发环境里点几下就能完成宠物和兽医管理。

我是老李，团队正准备把 Petclinic 推到预发环境，却被安全评审拦下：应用没有登录、没有角色、没有授权，任何人只要知道 URL 就能改数据。

为什么一个功能完全正常的应用，依然可能因为默认开放的接口和管理端点无法上线？

是继续沿用 Spring Boot 的默认安全配置，还是显式接管认证与授权？

如果选错，会不会出现“看似有登录、实际接口仍裸奔”的假安全？

# 01、故事

```text
周四 23:40 → 预发评审会议室 → 上线 Petclinic → 安全评审要求补登录与权限
```

周四晚上十一点四十，预发评审还在继续。

任务是让 Petclinic 通过上线前安全评审。

安全同事现场打开浏览器，直接访问 `/owners?lastName=`，页面正常返回；再访问 `/actuator/health`，也正常返回。

他追问：现在谁能改宠物信息？谁能看数据库连接信息？

我回答：目前没有登录，所有接口都开放。

评审结论只有一句：功能正常，但安全边界缺失，不能上线。

> 夜深评审灯未熄，
> 页面虽通心却虚。
> 接口裸奔无人守，
> 上线之门被锁闭。

# 02、问题

```text
需求变化：本地演示 → 生产上线 → 默认无认证 → 数据与管理端点暴露
```

Petclinic 原本是教学演示项目，默认不引入 Spring Security。

引入 Security 后，Spring Boot 会自动提供一个默认安全边界：所有请求需要登录，生成一个随机密码，并提供一个表单登录页。

但默认边界只解决“有没有登录”，不解决“谁能做什么”。

普通用户登录后仍可能访问 Actuator 管理端点，也可能修改核心数据。

可验证的验收标准是：匿名用户访问业务页面被重定向到登录页；普通用户只能查询；管理员才能修改核心数据；普通用户访问 Actuator 端点返回 403。

> 功能虽全无门禁，
> 默认开放藏风险。
> 登录只是第一道，
> 授权才是真护栏。

# 03、原理

```text
Security 进入 classpath → Boot 自动配置 → 默认认证与授权 → 覆盖需显式声明
```

Spring Boot 检测到 `spring-boot-starter-security` 后，会激活 `SecurityAutoConfiguration`。

默认行为包括：启用 HTTP Basic 与表单登录；创建一个内存用户 `user`；密码为启动时随机生成的 UUID；所有请求都需要认证；Actuator 端点同样被保护。

反直觉的是：默认安全配置并不会区分角色，也不会保护具体 URL 的写操作。

它只保证“未登录不能访问”，不保证“登录后不能越权”。

要覆盖默认行为，必须显式声明 `SecurityFilterChain` Bean，否则 Boot 的默认配置继续生效。

> 自动配置给底线，
> 随机密码护门前。
> 若要角色分权限，
> 显式声明才安全。

# 04、架构

```text
HTTP 请求 → SecurityFilterChain → 认证/授权 → Controller → Service → Repository
```

安全层位于 Controller 之前，由一组过滤器组成。

核心过滤器包括：`SecurityContextPersistenceFilter`、`UsernamePasswordAuthenticationFilter`、`AuthorizationFilt

er`、`CsrfFilter`。

认证负责确认“你是谁”，授权负责确认“你能做什么”。

本模块的边界是：只处理 HTTP 入口的安全决策，不侵入业务 Service。

收益是安全规则集中管理，代价是每个请求多经过若干过滤器。

适用条件是：所有需要登录和权限控制的 Web 应用。

> 请求先过安全链，
> 认证授权分两边。
> 业务逻辑不侵入，
> 边界清晰好扩展。

# 05、第一版实战

```text
JDK 17 + Spring Boot 3.2 + Petclinic → 引入 Security → 默认登录 → 验证 → V1
```

在 `pom.xml` 中加入依赖：

```xml
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
```

启动应用：

```bash
./mvnw spring-boot:run
```

启动日志中会出现类似内容：

```text
Using generated security password: 3f2a1b4c-5d6e-4f8a-9b0c-1d2e3f4a5b6c
```

访问 `http://localhost:8080/owners?lastName=`，会被重定向到 `/login`。

输入用户名 `user` 和日志中的随机密码，可以进入页面。

访问 `http://localhost:8080/actuator/health`，同样需要登录。

V1 成功标准：匿名访问被拦截，登录后可访问业务页面。

未在当前环境实测，以下为预期结果。

> 引入依赖一瞬间，
> 默认登录现眼前。
> 随机密码藏日志，
> 匿名访问被阻拦。

# 06、排查

```text
现象：登录后仍可改数据 → 怀疑授权缺失 → 检查 SecurityFilterChain → 确认默认配置 → 修复
```

问题一：普通用户登录后仍能访问新增、修改、删除接口。

怀疑是默认配置没有角色区分。

检查启动日志，确认没有自定义 `SecurityFilterChain`。

证据：访问 `/owners/new` 返回 200，而不是 403。

根因：Boot 默认配置只要求认证，不要求授权。

问题二：普通用户能访问 Actuator 端点。

怀疑是 Actuator 安全规则未单独配置。

检查请求：登录普通用户后访问 `/actuator/env`，返回 200。

根因：默认安全配置对所有请求一视同仁，没有对管理端点单独授权。

**错误尝试：** 只修改 `application.properties` 中的 `spring.security.user.roles`，以为能限制 Actuator，结果普通用户仍可访问。

> 登录只是第一关，
> 授权缺失仍可钻。
> 默认配置不区分，
> 越权访问在眼前。

# 07、优化

```text
V1 默认安全 → 证据：越权访问 → V2 显式 SecurityFilterChain + 角色授权
```

新增 `SecurityConfig` 类，显式声明安全规则：

```java
@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/", "/login", "/webjars/**", "/resources/**").permitAll()
                .requestMatchers("/owners/new", "/owners/*/edit", "/pets/new", "/visits/new").hasRole("ADMIN")
                .requestMatchers("/actuator/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            )
            .formLogin(form -> form
                .loginPage("/login")
                .defaultSuccessUrl("/", true)
            )
            .logout(logout -> logout.logoutSuccessUrl("/"))
            .csrf(csrf -> csrf.ignoringRequestMatchers("/api/**"));
        return http.build();
    }

    @Bean
    public UserDetailsService userDetailsService() {
        UserDetails admin = User.withUsername("admin")
            .password(passwordEncoder().encode("admin123"))
            .roles("ADMIN")
            .build();
        UserDetails user = User.withUsername("user")
            .password(passwordEncoder().encode("user123"))
            .roles("USER")
            .build();
        return new InMemoryUserDetailsManager(admin, user);
    }

    @Bean
    public PasswordEncoder passwordEncoder() {
        return new BCryptPasswordEncoder();
    }
}
```

同时新增自定义登录页 `login.html`，表单提交到 `/login`，并携带 CSRF token。

> 显式声明安全链，
> 角色授权分两边。
> 密码编码用 BCrypt，
> 管理端点只许管。

# 08、演进

```text
V2 角色授权 → 能力：最小权限 → 遗留：内存用户与静态规则
```

用 V1 同一组请求验证：

匿名访问 `/owners?lastName=`，重定向到 `/login`。

用 `user` 登录后访问 `/owners/new`，返回 403。

用 `admin` 登录后访问 `/owners/new`，返回 200。

用 `user` 登录后访问 `/actuator/health`，返回 403。

用 `admin` 登录后访问 `/actuator/health`，返回 200。

收益是核心写操作和管理端点只对管理员开放。

代价是用户和角色目前硬编码在内存中，重启后丢失。

遗留问题是：CSRF 对 API 路径直接关闭，后续需要更细粒度策略。

> 普通用户只能看，
> 管理端点只许管。
> 内存用户待持久，
> 静态规则待扩展。

# 09、洞见

```text
从“默认安全”到“显式安全”
```

## 默认安全不是完整安全
```text
默认配置 → 只认证 → 不授权 → 假安全
```

反直觉判断：引入 Spring Security 后应用并不会自动变安全。

默认配置只保证未登录不能访问，不保证登录后不能越权。

真正的安全边界必须显式声明角色和 URL 授权规则。

## 管理端点必须单独授权
```text
Actuator 暴露 → 默认同权 → 普通用户可看 → 信息泄露
```

反直觉判断：Actuator 端点不会因为“看起来是管理功能”就自动只对管理员开放。

必须显式配置 `/actuator/**` 的访问规则，否则普通用户登录后同样可以查看环境变量、配置信息。

## 密码编码器必须显式声明
```text
不声明 PasswordEncoder → 启动报错 → 无法登录
```

Spring Security 5 之后要求必须显式声明 `PasswordEncoder`。

如果使用 `{noop}` 前缀可以绕过，但生产环境必须使用 BCrypt 等强哈希。

## CSRF 不能一刀切关闭
```text
关闭 CSRF → 写操作暴露 → 跨站攻击
```

对纯 API 可以关闭 CSRF，但对表单提交必须保留。

一刀切关闭会让所有写操作暴露在跨站请求伪造风险中。

> 默认只是起跑线，
> 显式声明才安全。
> 管理端点要单独，
> 密码编码不能免。

# 10、系统落地

```text
浏览器 → SecurityFilterChain → Controller → Service → Repository → 数据库
```

原来 Petclinic 没有任何安全控制，所有页面和接口匿名可访问。

本篇增加了 Spring Security 依赖、显式安全过滤链、角色授权、密码编码、自定义登录页、Actuator 安全规则。

现在系统能区分匿名用户、普通用户和管理员，核心写操作和管理端点只对管理员开放。

下一篇还缺：用户与角色持久化到数据库、方法级安全、CSRF 细粒度策略、审计日志。

官方文档可参考 Spring Security 官方文档首页：https://docs.spring.io/spring-security/reference/index.html

> 安全边界已落地，
> 角色授权分清晰。
> 管理端点有护栏，
> 上线评审可开启。

# 11、小结

```text
三问三答：默认开放 → 显式接管 → 最小权限
```

第一问：为什么功能正常仍无法上线？

因为默认开放的接口和管理端点没有认证与授权，任何人都能改数据、看配置。

第二问：继续默认还是显式接管？

必须显式接管。默认配置只提供登录底线，不提供角色和 URL 授权。

第三问：选错会怎样？

会出现“有登录但无授权”的假安全，普通用户仍可越权修改数据或访问管理端点。

当前状态：Petclinic 已具备基于角色的最小权限安全边界，核心写操作和 Actuator 仅管理员可访问。

> 功能正常非终点，
> 安全边界是底线。
> 显式接管才可靠，
> 最小权限保上线。

# 12、作业

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

## 理解题：Spring Boot 默认安全配置到底做了什么？

默认配置启用表单登录和 HTTP Basic，生成随机密码，所有请求需要认证。

它不区分角色，不保护具体 URL 的写操作，也不单独限制 Actuator。

## 实战题：如何让普通用户只能查询，管理员才能修改核心数据？

显式声明 `SecurityFilterChain`，对 `/owners/new`、`/owners/*/edit` 等写操作路径配置 `hasRole("ADMIN")`。

查询路径配置 `authenticated()` 或 `hasAnyRole("ADMIN","USER")`。

同时提供 `UserDetailsService` 和 `PasswordEncoder`。

## 排障题：普通用户登录后仍能访问 `/actuator/env`，怎么排查？

先检查是否显式声明了 `SecurityFilterChain`。

如果没有，说明 Boot 默认配置生效，所有登录用户都能访问 Actuator。

如果有，检查 `/actuator/**` 的授权规则是否配置为 `hasRole("ADMIN")`。

## 架构判断题：把安全规则写在 Controller 里用 if 判断，是否可行？

不可行。安全规则应集中在 `SecurityFilterChain` 中，在请求进入 Controller 之前完成认证与授权。

写在 Controller 里会导致规则分散、容易遗漏，且无法保护静态资源和 Actuator 端点。

> 理解默认知边界，
> 实战显式写安全。
> 排障先查过滤链，
> 架构集中才稳健。

# 13、升华

```text
安全不是功能，是上线前提
```

Petclinic 从“功能正常”到“可上线”，差的不是业务代码，而是安全边界。

Spring Boot 的默认安全配置是起点，不是终点。

只有显式声明认证、授权、密码编码、CSRF 和 Actuator 规则，才能把教学项目变成生产级应用。

下一篇将把内存用户替换为数据库持久化，并引入方法级安全，让权限控制更贴近真实业务。

> 功能之上有安全，
> 默认只是起跑线。
> 显式声明筑护栏，
> 生产上线才心安。

**系列项目：** Spring 官方 Petclinic 宠物医院管理系统

**已完成：** 环境搭建、启动机制、依赖与自动配置、配置体系、Web 层、数据层、事务、远程调用、数据库迁移、缓存、并发、日志、测试、Testcontainers、Docker Compose、Actuator、可观测、自定义自动配置、容器构建

**本篇：** 引入 Spring Security，显式接管登录、角色、URL 授权、密码编码、CSRF 与 Actuator 安全

**下一篇：** 用户与角色持久化到数据库，引入方法级安全与审计日志

以下按示例系列设计，已有能力为示例前置能力，待与前文核对。

Petclinic 的页面、表单、数据库读写都已经跑通，开发环境里点几下就能完成宠物和兽医管理。

《SpringBoot4进阶实战》第9招 安全默认值要知道

从 Petclinic 上线受阻出发，用 Spring Security 逐步接管登录、角色、URL 授权、密码编码、CSRF 与 Actuator 安全，把教

架构师

编程语言

安全

后端

SpringBoot应用Petclinic因默认安全配置仅认证不授权导致无法上线。通过引入SpringSecurity显式声明SecurityFilterChain，实现基于角色的最小权限控制：匿名用户重定向登录、普通用户仅查询、管理员可修改数据并访问Actuator端点，密码使用BCrypt加密。

访问管理

代码解释

数据库

容器

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

《SpringBoot4进阶实战》第9招 安全默认值要知道-腾讯云开发者社区-腾讯云

《SpringBoot4进阶实战》第9招安全默认值要知道

《SpringBoot4进阶实战》第9招安全默认值要知道

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《SpringBoot4进阶实战》第9招 安全默认值要知道

《SpringBoot4进阶实战》第9招 安全默认值要知道

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《SpringBoot4进阶实战》第9招安全默认值要知道

《SpringBoot4进阶实战》第9招安全默认值要知道