Configuring Spring Boot to Remove Default Security Password

Problem Background

During Spring Boot application development, when Spring Security dependencies are included without complete security configuration, the system automatically enables default security settings. This results in warning messages like "Using default security password" appearing in application startup logs, along with a randomly generated default password. While this is a security protection mechanism provided by Spring Boot, in many practical application scenarios, developers prefer to completely disable this default behavior, especially when the application already has custom security policies configured.

Default Security Configuration Mechanism

Spring Boot's auto-configuration mechanism provides default security settings through the UserDetailsServiceAutoConfiguration class. When this class detects the absence of specific security-related beans in the application, it automatically configures an in-memory user details service and generates default user accounts with random passwords. This design aims to provide out-of-the-box basic security protection, preventing security vulnerabilities due to oversight.

According to Spring Boot official documentation, the default security configuration primarily includes:

• Basic HTTP authentication protecting all endpoints
• Built-in AuthenticationManager using in-memory storage
• Default username "user" with randomly generated password
• Access exemptions for static resource paths (such as /css/**, /js/**, etc.)

Primary Solutions

Excluding Auto-configuration Classes

The most direct and effective method is to exclude relevant auto-configuration classes in the main application class. Based on the best answer from the Q&A data, this can be achieved through the exclude property of the @SpringBootApplication annotation:

@SpringBootApplication(exclude = {SecurityAutoConfiguration.class})public class Application {    public static void main(String[] args) {        SpringApplication.run(Application.class, args);    }}

This approach completely disables Spring Boot's default security auto-configuration, thereby preventing the generation of default passwords. It's important to note that excluding SecurityAutoConfiguration also disables other related security configurations, making it suitable for scenarios requiring fully customized security policies.

Alternative Exclusion Approach

In some Spring Boot versions, directly excluding SecurityAutoConfiguration may cause application startup failures. In such cases, consider excluding more specific configuration classes:

@SpringBootApplication(exclude = {UserDetailsServiceAutoConfiguration.class})public class Application {    public static void main(String[] args) {        SpringApplication.run(Application.class, args);    }}

This method is more precise, disabling only the auto-configuration of user details service while preserving other security features. It's particularly suitable for integration scenarios with third-party security frameworks like OAuth2 or JWT.

Alternative Configuration Methods

Providing Custom AuthenticationManager

Another approach that aligns with Spring Boot's design philosophy involves providing a custom AuthenticationManager bean to override the default configuration:

@Configurationpublic class SecurityConfig {    @Bean    public AuthenticationManager authenticationManager() {        return authentication -> {            throw new AuthenticationServiceException("Authentication is disabled");        };    }}

This method leverages Spring Boot's conditional configuration mechanism - when the application detects the presence of an AuthenticationManager bean, it automatically disables the default user details service configuration.

Configuration in WebSecurityConfigurerAdapter

For applications already using WebSecurityConfigurerAdapter for security configuration, the same effect can be achieved by overriding the authenticationManagerBean method:

@Configuration@EnableWebSecuritypublic class CustomSecurityConfig extends WebSecurityConfigurerAdapter {    @Override    protected void configure(HttpSecurity http) throws Exception {        http.authorizeRequests().anyRequest().permitAll();    }    @Bean    @Override    public AuthenticationManager authenticationManagerBean() throws Exception {        return super.authenticationManagerBean();    }}

Configuration Properties Approach

In earlier Spring Boot versions, basic authentication could be disabled through application configuration files:

security.basic.enabled=false

However, it's important to note that this method is no longer recommended in Spring Boot 2.x versions, and the relevant configuration properties have changed.

Reactive Application Configuration

For reactive applications using Spring WebFlux, the corresponding configuration methods differ:

@SpringBootApplication(exclude = {ReactiveUserDetailsServiceAutoConfiguration.class})public class Application {    public static void main(String[] args) {        SpringApplication.run(Application.class, args);    }}

Alternatively, implementation through providing a ReactiveAuthenticationManager bean:

@Beanpublic ReactiveAuthenticationManager authenticationManager() {    return new JwtReactiveAuthenticationManager(jwtDecoder());}

Best Practice Recommendations

When selecting specific configuration methods, consider the following factors:

• Application Architecture: Traditional Servlet applications and reactive applications require different configuration approaches
• Security Requirements: Whether complete custom security policies are needed or only default password disabling is required
• Spring Boot Version: Support for configuration methods may vary across different versions
• Integration Needs: Whether integration with other security frameworks like OAuth2 or JWT is required

For most scenarios, excluding UserDetailsServiceAutoConfiguration is recommended as it maintains flexibility while having minimal intrusion into existing code.

Conclusion

Multiple implementation approaches exist for removing default security password warnings in Spring Boot, each with applicable scenarios and considerations. Developers should choose the most suitable configuration method based on specific application requirements and architectural characteristics. By understanding Spring Boot's auto-configuration mechanism and security framework principles, application security behavior can be more flexibly controlled, avoiding interference from unnecessary default configurations.