“MVC 安全”这几个字很多人的第一反应就是“Spring Security 加几个 Filter 不就完事了”。但我在真实项目里踩过不少坑之后越来越确信MVC 安全从来不是某一层单独能扛住的它必须贯穿 Model、View、Controller 三层形成一套完整闭环。搜索引擎里那些和 MVC 安全相关的热词比如“Spring MVC 某个方法特殊路由指定”“安全测试”“Windows 安全日志”“TLS 1.0 非安全协议”看似零散其实背后都指向同一个问题——我们在做 MVC 应用时到底把安全放在了哪个环节这篇文章我就从一个后端开发者的角度把 MVC 安全拆开揉碎从架构设计讲到 Spring MVC 实操再到安全测试和常见故障排查尽量说人话、给干货希望能帮你少走一些弯路。1. MVC 架构下的安全基线先把威胁面画清楚1.1 三层模型里的“安全三兄弟”MVC 把应用切成 Model、View、Controller 三块很多人就误以为安全也按这三块各管各的。但实际攻击往往不是针对某一层而是跨层串联的。比如一个典型的 SQL 注入入口在 View 层提交表单Controller 负责接收参数并转发给 Model最后 Model 拼 SQL 执行查询。如果你只在 Controller 做了参数校验Model 层却把校验过的数据又拼进了“动态表名”或“排序字段”一样有可能被绕过。所以我的经验是三层里的安全职责必须划分清楚但又不能各自为政。Model 层负责数据完整性校验、持久化安全、敏感数据加密。实体类里的字段类型、长度、业务规则校验要在 Model 层兜底更要防止把未经验证的原始参数直接写进 ORM 查询。View 层负责输出编码、内容安全策略、防 XSS。不管后端怎么校验前端渲染时都要假设“字符串可能包含恶意脚本”该转义就转义该 CSP 就 CSP。Controller 层负责路由权限、参数绑定、会话管理、CSRF 防护。它是 HTTP 入口也是权限判断的第一道关卡。这三层不是简单的“每层做自己的事”而是同一套安全上下文贯穿下来。比如用户登录状态Controller 需要从 Session 或 Token 里识别用户身份然后传给 Model 层做数据权限过滤最后 View 层渲染时再根据当前用户角色决定是否展示某些按钮。任何一层断了整个链路就漏了。1.2 从“默认信任”到“默认拒绝”很多 MVC 项目刚起步时都是“默认信任”模式只要用户能访问到方法就允许他执行只要表单传了参数就照单全收。这种开发速度很快但上线后就是灾难。我接手过一个老项目Controller 里几乎所有接口都是RequestMapping(/xxx)没有方法级权限没有参数白名单甚至连登录校验都只靠前端跳转。结果一个普通用户直接构造 URL 就能拿到管理员后台的数据这就是典型的“越权访问”。正确的思路是默认拒绝所有接口默认不允许访问除非显式声明权限所有参数默认不安全除非显式校验。具体落地到 MVC 上至少要守住三条原则路由权限白名单Controller 的每个方法都明确标注允许哪些角色或权限访问而不是只对“特殊接口”做防护。参数校验白名单使用 DTO/VO 接收参数只包含允许客户端传入的字段避免自动绑定把多余字段塞进 Model。最小权限原则给角色分配权限时只给完成功能所需的最小权限集合。能读就不给写能查列表就不给导出全量。“默认拒绝”听起来会增加工作量但一旦形成习惯项目后期反而更省心。因为安全边界清晰了审计代码时只需要关注那些显式放行的地方而不是满地找漏洞。2. 用 IDEA Maven 创建一个安全的 Spring MVC 项目2.1 项目骨架搭建与安全依赖引入假设你要从零搭一个 Spring MVC 项目最顺手的方式就是 IDEA 里基于 Maven 创建。我是用 IDEA 2026.1.3 试过完整流程大概这样在 IDEA 里新建 Maven 项目选择maven-archetype-webappGroupId 和 ArtifactId 按自己项目命名。在pom.xml里引入 Spring MVC 和 Servlet 依赖properties spring.version5.3.31/spring.version !-- 或者 6.x看 JDK 版本 -- /properties dependencies dependency groupIdorg.springframework/groupId artifactIdspring-webmvc/artifactId version${spring.version}/version /dependency dependency groupIdjavax.servlet/groupId artifactIdjavax.servlet-api/artifactId version4.0.1/version scopeprovided/scope /dependency !-- 安全框架 -- dependency groupIdorg.springframework.security/groupId artifactIdspring-security-web/artifactId version${spring.version}/version /dependency dependency groupIdorg.springframework.security/groupId artifactIdspring-security-config/artifactId version${spring.version}/version /dependency /dependencies在 web.xml 里配置DispatcherServlet如果你用纯 Java Config也可以直接用AbstractAnnotationConfigDispatcherServletInitializer注册这样可以省掉 web.xml。这里有个容易被忽略的点Spring Security 必须要有一个SecurityFilterChain的过滤器链路并且这个链路要放在DispatcherServlet之前才能在请求进入 Controller 之前完成身份认证和权限校验。如果用 Java Config可以用AbstractSecurityWebApplicationInitializer来注册它会自动把 Spring Security 的 Filter 插入 Servlet 容器。2.2 基于 Java Config 的 Spring Security 配置Spring Security 5.7 之后官方推荐用SecurityFilterChain风格来替代继承WebSecurityConfigurerAdapter。写一个最基础的安全配置大概长这样Configuration EnableWebSecurity public class SecurityConfig { Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth - auth .requestMatchers(/login, /css/**, /js/**, /images/**).permitAll() .requestMatchers(/admin/**).hasRole(ADMIN) .anyRequest().authenticated() ) .formLogin(form - form .loginPage(/login) .permitAll() ) .logout(logout - logout .logoutUrl(/logout) .logoutSuccessUrl(/login) ) .csrf(csrf - csrf.disable()) // 开发期可以先关掉上线前务必打开 .sessionManagement(session - session .sessionFixation().changeSessionId() .maximumSessions(1) ); return http.build(); } Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } }这段配置虽然短但背后有几个“为什么”需要讲清楚为什么静态资源要permitAll因为登录页本身需要加载 CSS/JS如果先拦截了页面就白屏了。但放行静态资源时要注意/js/**或/images/**路径里绝对不能有后端脚本或敏感文件否则等于把攻击面扩大了。为什么/admin/**用hasRole(ADMIN)这是基于角色的粗粒度权限。你还可以用hasAuthority(ROLE_ADMIN)两者本质一样。更细的话可以在方法上用PreAuthorize后面会单独讲。为什么用 BCrypt 编码密码因为明文密码一旦数据库泄露所有账号全完蛋。BCrypt 自带随机盐相同密码每次加密结果都不同能有效对抗彩虹表。为什么设置sessionFixation().changeSessionId()这是防“会话固定攻击”。用户登录前必须更新 Session ID防止攻击者把自己已经拥有的 Session ID 塞给用户。注意一点csrf.disable()在调试阶段可以但上线时必须打开。CSRF 防护主要针对“跨站请求伪造”当你的应用基于 Cookie 或 Basic Auth 时尤其要小心。很多人为了图方便关闭它结果被第三方攻击者诱导用户在不知情下提交表单这是非常典型的真实漏洞。2.3 把安全配置和 MVC 配置协同起来Spring MVC 也会有自己的配置比如拦截器、跨域配置、静态资源映射。这些配置和安全框架的过滤器链不是互相替代而是重叠防护。举个例子你可以在 Spring MVC 层注册一个校验登录状态的拦截器但这样只能挡住“没登录”的请求挡不住“登录了但没权限”的请求。所以正确的姿势是Spring Security 管认证和授权Spring MVC 管参数校验和视图渲染两者各司其职。在 Java Config 中可以这样注册拦截器和跨域Configuration EnableWebMvc public class MvcConfig implements WebMvcConfigurer { Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()).addPathPatterns(/**); } Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOrigins(https://trusted.example.com) .allowedMethods(GET, POST, PUT, DELETE); } }CORS 这里的allowedOrigins一定不要配成*尤其是带 Cookie 的跨域请求。相信我把来源域名白名单写清楚能省掉后面一大堆“凭据跨域异常”的排查时间。3. Controller 与路由层的安全细节3.1 方法级路由的特殊指定与访问控制热搜词里有一条“MVC 某个方法特殊路由指定”这在实际项目中很常见。比如同一个资源列表接口允许所有登录用户看但删除接口只允许管理员调或者同一个方法某些路径参数不同触发的业务逻辑也不一样。Spring MVC 里实现特殊路由指定无非这几种GetMapping(/users)查列表GetMapping(/users/{id})查详情DeleteMapping(/users/{id})删除。同一个 URL 下用params条件区分如GetMapping(value /search, params typeadvanced)只匹配指定参数。使用RequestMapping中的consumes和produces来限制 Content-Type 和 Accept。但路由指定之后安全依然要跟着走。一个常见坑是方法路由“特殊化”了权限却没有“特殊化”。比如你给/users/export单独配了个路由却忘了加PreAuthorize导致任何登录用户都能导出全量数据。方法级权限控制我强烈推荐用 Spring Security 的注解。先开启Configuration EnableWebSecurity EnableGlobalMethodSecurity(prePostEnabled true) public class SecurityConfig { ... }然后在 Controller 方法上写GetMapping(/admin/users/{id}) PreAuthorize(hasRole(ADMIN)) public User getUser(PathVariable Long id) { return userService.getUserById(id); }如果权限表达式比较复杂比如“操作人必须是自己或管理员”可以用PreAuthorize(hasRole(ADMIN) or #id authentication.principal.id)这里面能直接引用方法参数和 principal非常方便。我自己的经验是方法级权限应该用在“业务操作类”接口上而不是每个查询接口都加。因为太碎了会导致配置泛滥审计困难。核心原则是读操作按角色粗粒度控制写操作按具体权限细粒度控制。3.2 输入绑定与参数校验别让恶意参数进到 ModelController 里最常见的风险之一就是“参数绑定引发的越权”。假设 User 实体有id、username、password、role字段如果直接用 User 对象接收 POST 请求体攻击者传一个role:ADMINSpring MVC 会自动帮你绑定到对象上即使前端页面根本没有这个字段。这就是我前面提到的“默认信任”。解决方法是用专用的UserCreateForm、UserUpdateForm这种 DTO 做接收参数只包含允许客户端传的字段。在 DTO 字段上加上NotNull、Size、Pattern等校验注解。Controller 方法参数加上Valid或Validated校验失败会抛出异常再统一处理。示例public class UserCreateForm { NotBlank(message 用户名不能为空) Size(max 32) private String username; NotBlank(message 密码不能为空) Size(min 8, max 64) private String password; // 没有 role 字段天然避免越权绑定 }PostMapping(/users) PreAuthorize(hasRole(ADMIN)) public User createUser(Valid RequestBody UserCreateForm form) { return userService.createUser(form.getUsername(), form.getPassword()); }另外如果你的接口返回 JSON 数据一定要配置 Jackson 的“默认未知属性忽略”或“失败模式”。否则如果前端多传了一个未知字段接口可能直接 400也可能反向绑定到内部对象上。推荐在 application.properties 里配置spring.jackson.deserialization.fail-on-unknown-propertiesfalse3.3 CSRF 防护与 CORS 策略CSRF 和 CORS 经常被放在一起说但它们是两码事。CSRF 是“攻击者借用用户的已认证状态发起请求”CORS 是“浏览器限制跨域读取响应”。Spring Security 默认开启 CSRF 防护当你使用 POST、PUT、DELETE 等修改性请求时需要在上表单或 AJAX 请求中携带 token。在 Spring MVC 后端渲染模板的场景下可以使用 Thymeleaf 的th:action自动生成 CSRF Token。如果是前后端分离那就需要前端从 cookie 里读取XSRF-TOKEN并在每次请求头里带上X-XSRF-TOKEN。Spring Security 也提供了CsrfTokenRepository来配合 Cookie 传输。CORS 策略则要在安全框架里也配置一遍而不是只在 Spring MVC 配置。因为 Spring Security 的过滤器链在 MVC 之前如果安全层没有允许某个跨域来源MVC 层的 CORS 配置根本没有机会生效。推荐在 Security 的http.cors()开启并单独定义CorsConfigurationSourceBeanBean public CorsConfigurationSource corsConfigurationSource() { CorsConfiguration config new CorsConfiguration(); config.setAllowedOrigins(Arrays.asList(https://trusted.example.com)); config.setAllowedMethods(Arrays.asList(GET, POST, PUT, DELETE, OPTIONS)); config.setAllowedHeaders(Arrays.asList(*)); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return source; }注意allowedOrigins不要用*尤其allowCredentials(true)时*是被规范禁止的。别问问就是我踩过。4. 安全测试与常见问题排查实录4.1 手动/自动化安全测试Jmeter、Burp Suite 与证书问题安全测试是 MVC 项目上线前的关键一步。我一般分两层做第一层是接口功能安全测试用 Postman 或 Jmeter 直接构造异常请求比如越权参数、非法字段、超大文件等。这里有个常见问题用 Jmeter 测试 HTTPS 接口时常常提示证书不受信任。解决办法是把自己应用的证书或者公司内网测试证书导入到 JDK 的cacerts信任库中keytool -import -alias myCert -file yourCert.cer -keystore %JAVA_HOME%/jre/lib/security/cacerts -storepass changeit导入后重启 Jmeter再跑压测和安全测试就顺畅多了。但要注意这只是解决测试环境的证书信任问题生产环境的证书链依然要合法合规。第二层是渗透测试可以用 Burp Suite 或者 Owasp ZAP 做被动扫描和主动扫描。重点看看这些点是否存在 SQL 注入尤其是 Model 层拼接查询时是否存在 XSS尤其是 View 层输出用户内容时是否泄漏敏感错误信息比如 SQL 异常直接回显给客户端Cookie 的 HttpOnly、Secure、SameSite 属性是否正确未授权访问是否真的被拦截。这里分享一个我常用的排查思路抛开扫描器直接模拟“普通用户”操作。用最低权限的账号登录系统把所有页面和接口都点一遍再用 Burp 抓包改参数去尝试越权。这种手工“坏心思”测试往往比自动化扫描更能发现逻辑漏洞。4.2 常见安全报错处理TLS、安全日志、安全启动等开发过程中经常会遇到一些环境安全类报错看着跟 MVC 代码无关但会直接卡你进度。比如浏览器访问 HTTPS 站点时提示“此网站无法提供安全连接发送的响应无效”。这通常不是 MVC 代码问题而是 Web 服务器 TLS 配置错误。常见原因包括服务器只配置了旧的 TLS 协议版本比如 TLS 1.0而浏览器默认不再支持。证书链不完整服务端没有下发中间证书。服务器返回的 Content-Type 不对导致浏览器无法解析。解决方法是在 Nginx/Tomcat 里强制使用 TLS 1.2 或更高版本并完整配置证书链。如果出现“协商的 TLS 1.0 是非安全协议”的警告说明服务器还在用老版本协议需要修改配置例如 Nginx:ssl_protocols TLSv1.2 TLSv1.3;再比如 Windows 相关的问题“你的设备中缺少重要的安全和质量修复”或“Windows 安全中心无法打开”。虽然这是操作系统层面的事但开发者电脑上发生的话也会打断联调。一般做法是运行Windows Update或者用 DISM 修复系统映像。如果项目本身跑在服务器上更要关注安全补丁更新避免因系统漏洞被拖库。至于“安全日志”我看很多人只在 Windows 系统出问题时才想起来查看。其实在 MVC 应用里也应该有自己的“安全日志表”或“安全事件日志”记录登录失败、越权尝试、敏感操作等。出了问题先查日志再查代码效率能高很多。4.3 快速排查清单下面这份清单是我做安全联调时经常过一遍的速查表可以参考检查项合格标准认证方式登录接口有防暴力破解机制密码加密存储会话管理登录成功更换 Session ID空闲超时自动失效路由权限每个 Controller 方法都有明确的权限或角色要求参数校验所有外部输入都经过白名单校验未绑定多余字段输出防护动态内容输出前做 HTML 编码CSP 头已配置CSRF所有修改性请求都验证 TokenCORS跨域来源白名单精确不带*错误处理不向客户端暴露堆栈和 SQL 细节日志审计关键操作和异常行为有安全日志记录HTTPSTLS 1.2证书链完整Cookie 带 Secure 属性5. 我的实操心得与避坑总结5.1 三个容易忽略的细节第一静态资源放行时一定要慎用/**。有些人图省事直接把所有静态资源路径配成permitAll()结果把后台管理页面的所有 JS 也放行了。虽然 JS 只在前端渲染但若其中包含 API 地址和角色判断逻辑就会给攻击者提供极有价值的信息。我习惯把静态资源放在/assets/*、/static/*这种统一前缀下只放行这些目录。第二错误信息泄露常常被忽略。默认的 Spring Boot 白标错误页会返回详细的异常信息虽然对开发友好但生产环境必须关闭。可以在application.properties里设置server.error.include-messagenever server.error.include-stacktracenever spring.mvc.throw-exception-if-no-handler-foundtrue同时定义一个全局异常处理器把已知业务异常转成友好的提示把未知异常统一记录日志后返回“系统繁忙”。第三SESSION 超时后的 AJAX 请求处理。很多前后端分离项目用户登录超时后再点一个按钮会发现页面一直在转圈没有任何提示。这是因为 AJAX 请求收到了 302 跳到登录页前端却没有处理。正确的做法是在 Controller 里统一判断如果是 AJAX 请求就返回 401 JSON前端再根据 401 跳转登录。这个在很多团队里都是上线后才发现的痛点。5.2 安全开发 Checklist 的落实最后说一点管理上的心得。安全光靠一个“安全负责人”盯是没有用的必须把检查项揉进日常开发流程里。我在项目里推行的是一个极简 Checklist每个新接口必须写明谁可以访问角色/权限、参数从哪来、返回给谁看。涉及钱财、隐私、删除类操作必须走二次确认和审计日志。后端代码评审时把关的三个重点是参数是否用 DTO 接、是否有方法级权限、SQL 是否用了预编译。每次迭代结束前至少用扫描器跑一轮接口安全基础扫描。说实话这套流程不是我在项目第一天就想到的而是经历了线上越权、数据误删之后一点点补上的。MVC 安全真正难的不是某个技术点而是“把每一个请求都当作可疑人员来对待”的那种持续敏感度。我现在看代码第一眼不是看业务逻辑而是看这个入口有没有认证这个参数有没有校验这个输出有没有编码。习惯了之后反而觉得这些约束让代码更干净也让半夜被叫起来排查安全问题的情况少了很多。
