Security Misconfiguration in Spring Boot – OWASP A05
Fast recall
Quick revision
Core answer
Interview-ready guide
Interview answer
Security Misconfiguration is an unsafe or incomplete setting in the deployed system. In the current OWASP Top 10:2025 it is A02; A05 is its 2021 number. Examples include exposing sensitive management data, leaving a development console reachable, returning detailed exceptions, trusting forwarding headers from arbitrary clients, or granting a service more cloud or database permission than it needs.
For Spring Boot, I would expose only the Actuator endpoints required for operations and protect them with both network and application controls. I would keep H2 console and debug behavior in development, use a consistent error response without stack traces, and review API documentation exposure. I would also check the reverse proxy and platform because TLS, client IP, and secure-cookie behavior can be wrong even when the Java properties look correct.
The control is environment-specific hardening plus verification. Profiles help, but the important artifact is the effective production configuration, tested after deployment and monitored for drift.
Security Misconfiguration in Spring Boot – OWASP A05
Direct Answer
Security Misconfiguration is A02 in OWASP Top 10:2025; it was A05 in 2021. It includes an unsafe setting, unnecessary feature, exposed management endpoint, overly detailed error, permissive cloud policy, or missing hardening. Spring Boot examples arise when teams enable broad Actuator exposure, deploy the H2 console, publish sensitive health details, trust spoofable proxy headers, or expose debug errors. Review the effective production configuration and restrict each feature to the users and network that need it.
Code Example
// application-prod.properties
// Restrict Actuator endpoints to internal monitoring only
management.endpoints.web.exposure.include=health,info
management.endpoint.health.show-details=when-authorized
management.endpoints.web.base-path=/internal/actuator
// Disable H2 console completely in production
spring.h2.console.enabled=false
// Hide detailed error information
server.error.include-message=never
server.error.include-stacktrace=never
server.error.include-exception=false
server.error.include-binding-errors=never
@Configuration
public class ActuatorSecurityConfig {
@Bean
public SecurityFilterChain actuatorSecurity(HttpSecurity http) throws Exception {
return http
.securityMatcher("/internal/actuator/**")
.authorizeHttpRequests(auth -> auth
.requestMatchers("/internal/actuator/health").permitAll()
.requestMatchers("/internal/actuator/**").hasRole("ADMIN")
)
.httpBasic(Customizer.withDefaults())
.build();
}
}
Common Mistakes & Pitfalls
- Copy-Pasting Dev Config: Using the same application.properties in production as development without reviewing each property—features like
spring.h2.console.enabled=trueslip through to production. - Assuming Framework Security: Believing Spring Boot auto-secures its own features like Actuator or H2 console by default—it doesn't, convenience wins over security in development mode.
- Exposing All Actuator Endpoints: Setting
management.endpoints.web.exposure.include=*to make monitoring setup easier, exposing dangerous endpoints like /shutdown, /heapdump, and /env that leak secrets or allow denial of service. - Forgetting Swagger in Production: Leaving Swagger UI or SpringDoc OpenAPI endpoints publicly accessible, giving attackers a complete map of your API surface including undocumented endpoints and request formats.
Check your understanding
Answer these without looking back at the article.
- How do you secure Spring Actuator endpoints in production?
- What information do stack traces in error responses reveal to an attacker?
- How do you write a deployment security checklist for a Spring Boot app?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.