为何Spring Security Config不应直接用于应用？依赖配置存疑

Great question—this is a common point of confusion when working with Spring Security, so let’s break it down clearly:

Why does spring-security-config warn against direct use? #

The core reason is that most code in this package is internal infrastructure for Spring Security's configuration system, not part of the public, stable API intended for application developers. Spring’s team reserves the right to modify, rename, or remove these internal classes/methods between versions without maintaining backward compatibility. If you tie your application to these non-public APIs, you’ll likely run into breaking changes when upgrading Spring Security later.

That said, there are some public-facing classes in this package (like WebSecurityConfigurerAdapter, SecurityConfigurer, or HttpSecurity) that are explicitly documented for developer use—these are exceptions to the "do not use" rule.

What’s the deal with Baeldung’s <scope>runtime</scope> suggestion? #

The runtime scope recommendation applies to standard Spring Security usage scenarios where you don’t need to directly reference classes from spring-security-config in your own code. For example:

• Using auto-configuration (Spring Boot’s default security setup)
• Defining security rules via annotations like @EnableWebSecurity without extending internal config classes
• Using the newer Lambda-based configuration style that avoids direct subclassing

In these cases, Spring’s core framework handles loading and using spring-security-config under the hood at runtime, so you don’t need the dependency during compilation.

What if you do need to use code from this package? #

If your application requires custom security logic that relies on public APIs from spring-security-config (like extending WebSecurityConfigurerAdapter to define custom authentication providers, or building a custom SecurityFilterChain with HttpSecurity), then changing the scope to <scope>compile</scope> is completely valid and necessary.

Just keep these best practices in mind:

• Stick to classes/methods that are explicitly documented in the Spring Security reference guide—avoid using internal classes marked with @Internal or those without public API annotations.
• When upgrading Spring Security versions, thoroughly test any custom code that depends on this package to catch breaking changes early.

For example, if you have code like this:

@Configuration
@EnableWebSecurity
public class CustomSecurityConfig extends WebSecurityConfigurerAdapter {
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http.authorizeRequests()
            .antMatchers("/public/**").permitAll()
            .anyRequest().authenticated();
    }
}

You must set the scope to compile, since WebSecurityConfigurerAdapter and HttpSecurity are part of spring-security-config and your code needs them during compilation.

Final Takeaway #

The "do not directly use" note is a warning to avoid internal implementation details, not all code in the package. Baeldung’s runtime scope is a best practice for standard use cases, but don’t hesitate to switch to compile scope when you need to work with the package’s public, documented APIs.

内容的提问来源于stack exchange，提问作者Abel Matos