No. When Spring Security is on the classpath, Spring Boot creates a single in memory user named user with a random password printed in the log at WARN level. The docs say this generated password is for development use only and that your security configuration must be updated before production.
What you get out of the box
The Spring Boot security documentation lists the default web application features: a UserDetailsService bean with an in memory store and one user with a generated password, plus form based login or HTTP Basic depending on the Accept header. You can set spring.security.user.name and spring.security.user.password to change the credentials.
A property file password is still a shared secret in a text file. It is a stopgap, not an identity system.
Why it is a risk
- The password is written to application logs, which are often shipped to shared systems.
- It changes on every start, so teams are tempted to pin it in a property file.
- It gives you one account with no roles, no audit trail per person, and no way to revoke a single user.
- If you pin a simple value to "make it work", you may have created a default credential.
What to replace it with
| Need | Typical approach |
|---|---|
| Users stored in your database | A custom UserDetailsService with hashed passwords |
| Single sign on | OAuth2 login or SAML support, which Spring Boot also covers in its docs |
| Machine clients | Token based authentication with a resource server |
Add your own SecurityFilterChain for web rules, and remember that doing so turns off default web security including Actuator protection. Read our note on that behaviour. The Boot docs add that to also switch off the default user configuration you add a UserDetailsService, AuthenticationProvider or AuthenticationManager bean.
Steps
- Search your logs for the generated password line. If it appears in production logs, auth was never configured.
- Search properties for
spring.security.user.password. Remove it from anything that ships. - Provide a real user store or identity provider.
- Hash stored passwords with the default delegating encoder. See which password encoder Spring uses.
- Rotate any credential that was ever pinned in a repository.
- Test that the old default user cannot sign in.
A worked example
A small internal tool is deployed with the starter dependency and no security configuration. It works because the generated user exists. Someone finds the password in the first startup log and pins it in a property file so the pod can restart without changing credentials. A year later the tool holds customer data, is shared across teams, and still has one account with one password that everyone knows.
The fix is the same on day one and on day four hundred: introduce real identities, remove the pinned property, and rotate. Day one is cheaper.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Why do I not see the password in my logs?
The docs say the logging category for security auto configuration must allow WARN level messages or the password is not printed.
Is HTTP Basic with the default user acceptable behind a firewall?
It is still one shared credential. Use real identities, with a firewall as an additional layer.
Sources
Last reviewed: 19 October 2026.
