How do you secure a Spring Boot application against common vulnerabilities (e.g., exposing actuator endpoints, default credentials)?
Quick Answer
Beyond authentication/authorization logic itself, common Spring Boot hardening steps include: restricting or securing Actuator endpoints (never exposing /actuator/env, /actuator/heapdump, or similar sensitive endpoints publicly without authentication), never shipping default/example credentials into production configuration, keeping dependencies patched against known CVEs, enabling HTTPS and appropriate security headers, validating and sanitizing all external input (not just relying on Bean Validation for business rules but also against injection), and ensuring error responses don't leak internal stack traces or implementation details to clients.
Detailed Answer
Beyond the core authentication/authorization mechanics, a number of practical hardening steps consistently matter for real Spring Boot deployments:
1. Lock down Actuator endpoints. By default, only /actuator/health and /actuator/info are exposed over HTTP; but it's common (and risky) for teams to broaden management.endpoints.web.exposure.include for convenience without also securing access. Endpoints like /actuator/env (environment variables, potentially including secrets), /actuator/heapdump (a full memory dump, potentially containing sensitive in-memory data), and /actuator/shutdown should never be exposed to the public internet without authentication — ideally, expose Actuator on a separate management port, restricted at the network level, and additionally require authentication for anything beyond basic health checks.
2. Never ship default/example credentials. Default admin passwords, example API keys left in application.yml, or hardcoded test credentials making their way into a production build are a recurring, entirely preventable class of real-world breaches — configuration for secrets should come from environment variables, a secrets manager, or a vault, never a checked-in default value intended "just for now."
3. Keep dependencies patched. Spring Boot applications pull in a large dependency tree; known CVEs in transitive dependencies (a vulnerable Jackson version, a vulnerable logging library) are a common real-world attack vector — regular dependency updates and automated vulnerability scanning (e.g., OWASP Dependency-Check, GitHub Dependabot) are a baseline expectation, not optional.
4. Enforce HTTPS and set appropriate security headers. Terminate/require TLS in production, and configure Spring Security's default security headers (X-Content-Type-Options, X-Frame-Options/Content-Security-Policy, Strict-Transport-Security) rather than disabling them — Spring Security enables sensible header defaults automatically, but they're sometimes accidentally stripped by an intermediate proxy or explicitly disabled during debugging and never re-enabled.
5. Validate and sanitize all external input, not just via Bean Validation for basic shape/format rules — inputs used to build a SQL query (always use parameterized queries/JPA, never string-concatenated SQL), a file path (validate against path traversal), or a redirect URL (validate against open-redirect abuse) all need targeted scrutiny beyond generic @Valid annotations.
6. Don't leak internal details in error responses. A default or poorly-configured error handler that returns a full stack trace, internal class names, or a raw exception message to the client hands an attacker free reconnaissance information — a @RestControllerAdvice-based global exception handler (see the exception-handling question) should return a generic, consistent error shape for anything beyond the specific, intentional error cases the API is designed to communicate.
None of these are exotic — they're consistently the actual root causes behind real Spring Boot application incidents, which is exactly why they're worth deliberately checking rather than assuming "Spring Security is on, so we're covered."