Suppress the Spring Security Generated Password Warning

If your Spring Boot app logs a generated security password on every startup, it means the default in-memory user details service is still active. Read on to find out why it happens and how to turn it off cleanly.

When you start a Spring Boot app with Spring Security on the classpath, you may see something like this in the logs:

Using generated security password: abfdd22b-4a98-4418-b482-9b89d84fc011

This generated password is for development use only. Your security configuration must
be updated before running your application in production.

This is harmless in isolation, but it signals that part of Spring Security's default autoconfiguration is still running alongside your custom setup, which is not what you want.

Why It Happens

Spring Boot includes a class called UserDetailsServiceAutoConfiguration that activates whenever no UserDetailsService bean is found in the application context. It creates an in-memory user with the username user and a randomly generated password, logging that password so you can log in during development.

The catch is that this autoconfiguration fires even when you have a fully custom security setup - for example, a SecurityFilterChain using JWT-based authentication via a custom filter. Spring has no way to infer that your custom filter makes the in-memory user irrelevant, so it creates one anyway.

The Fix

Exclude UserDetailsServiceAutoConfiguration from the @SpringBootApplication annotation on your main application class:

import org.springframework.boot.autoconfigure.security.servlet.UserDetailsServiceAutoConfiguration;

@SpringBootApplication(exclude = {UserDetailsServiceAutoConfiguration.class})
public class YourApplication {

    public static void main(String[] args) {
        SpringApplication.run(YourApplication.class, args);
    }
}

This tells Spring Boot not to run that autoconfiguration at all, so no in-memory user is created and the warning disappears.

When This Is Safe to Do

This exclusion is safe when your application provides its own authentication mechanism and does not rely on Spring's default UserDetailsService anywhere - for example, when you are using JWT tokens validated by a custom OncePerRequestFilter. If your app uses Spring Security's form login, HTTP Basic, or any feature that calls UserDetailsService under the hood, excluding this class will break those features.