Spring Boot

Spring Boot’s security defaults are good — better than Express’s, and on error handling better than Django’s. Only /health is exposed over HTTP, configuration values are sanitized, stack traces are never returned, CSRF is on, and seven response headers are set without configuration.

So this cluster is mostly about two things: what a version migration changes, and what one wildcard undoes.

Check what you are actually running

./mvnw dependency:list | grep -E 'spring-boot|spring-security'
# or
./gradlew dependencies --configuration runtimeClasspath | grep -E 'spring-boot|spring-security'

Spring Boot 4.1.0 is current, and it manages Spring Framework 7.0.8 and Spring Security 7.1.0. Spring Security 6.5 was the last 6.x release; its own migration guide recommends going to 6.5 first, applying that version’s preparation steps, and only then moving to 7.

This matters for reading advice. WebSecurityConfigurerAdapter was removed in 6.0, so anything written against it predates 2022 and is now two majors stale — it describes a class that does not exist.

The finding most audits miss

Spring Boot secures Actuator for you, but only while no SecurityFilterChain bean exists. Defining one — which the Spring Security 6 migration makes mandatory — makes that auto-configuration back off.

A required security upgrade therefore removes a protection somewhere else, silently, with no warning and no failing test. That relationship is the spine of this cluster: it runs from SecurityFilterChain through exposure to the threat page.

Run these two checks first

curl -s https://example.com/actuator | python3 -m json.tool     # what is exposed
grep -rn "csrf.*disable\|exposure.include" src/main/resources src/main/java

The first tells you what is reachable from outside, which is the only answer that counts — profiles and environment variables override the YAML in your repo. The second finds the two lines that account for most findings on this checklist.

The checklist

Severity is the exposure a control closes, not how often it gets recommended. Several entries here are verify pages rather than configure pages, because the shipped default is already correct — that is a real finding about this framework, not padding.

SecurityFilterChain and what defining one turns offAuthorization rules that compile but no longer mean what they didSeverity: critical

Actuator endpoint exposureConfiguration, beans, mappings and heap contents reachable over HTTPSeverity: high

The generated user and passwordA known username with a password sitting in your startup logsSeverity: high

CSRF is on by default — don't switch it offState-changing requests forged from another siteSeverity: high

What /env actually showsCredentials read from configuration endpointsSeverity: medium

Error responses and stack tracesStack traces and internal messages returned to clientsSeverity: medium

Default security headersHeaders silently lost when the defaults are replaced rather than extendedSeverity: low

Actuator exposed to the internetHeap dumps, configuration and runtime control reachable without authenticationSeverity: critical

0 of 8 applied

What this cluster does not cover

The JVM, the servlet container’s own configuration, TLS termination, and the reverse proxy in front of you. That is the server’s half rather than the application’s — see application vs server for the dividing line.