Update initialization order in `SpringApplication` to ensure
`setAllowBeanDefinitionOverriding` is called before initializiers.
This prevents an initializer from accidentially overriding a bean.
Closes gh-50264
While remote code execution is a feature of remote DevTools,
hardening of the deserialization of ClassLoaderFiles is not without
benefit. Not least, it should prevent false-positive reports from
AI-based security scanners that look at the code in isolation without
understanding the full context of the feature.
It should be noted that this hardening in no way protects against
remote code execution and the use of remote DevTools remains an
opt-in feature that should only be enabled in a trusted setting and
secured with a sufficiently complex secret. It remains the case that
an attacker who compromises the secret and has network access to the
remote application can achieve RCE by uploading a serialized
ClassLoaderFiles payload that adds malicious code and/or resources
to the application.
Closes gh-50272
Update the default implementation of `WritableJson.toByteArray()`
to reduce the amount of garbage created from repeated calls.
Prior to this commit, each call would create a new
`ByteArrayOutputStream` and `OutputStreamWriter` to create the
byte array. Writing structured JSON results in many calls to
the `toByteArray()` method, which means we repeatedly create
and destroy the `ByteArrayOutputStream` and `OutputStreamWriter`
objects. Furthermore, both contain buffers that are often
expanded and will overlap with each other.
The updated implementation uses a custom `Appendable`
implementation that uses a single `ByteBuffer` buffer. It also
has a `ThreadLocal` cache so that repeated calls from the same
thread can reuse the buffer. The cache uses a `SoftReference`
to ensure that the JVM can reclaim space if needed (for example,
if a large JSON line was written).
Closes gh-49428
The links endpoint only supports GET, so its matcher is now hardcoded
to GET. withHttpMethod(...) continues to apply only to endpoint paths
and the behaviour is documented on its javadoc.
Signed-off-by: Lee JiWon <dlwldnjs1009@gmail.com>
See gh-50095
Previously, Spring Security wouldn't necessary allow cross-origin
requests to /cloudfoundryapplication, despite the underlying handler
mapping doing so.
Since 6.2, Spring Security enables CORS with default configuration if
there are any UrlBasedCorsConfigurationSource beans in the context.
This default configuration will then use a bean named
corsConfigurationSource as its source of CORS configuration. If it
doesn't find such a bean, it'll use the mvcHandlerMappingIntrospector
bean as a source. This latter case works as it means that the
CORS configuration of the underlying handler mapping is used.
In the case where a bean named corsConfigurationSource is used, this
will break /cloudfoundryapplication if the bean's CORS configuration
for /cloudfoundryapplication does not allow it. This has only been
a problem since Spring Boot 3.5 where we switched from using
ignoring() to using permitAll() to configure the security of
/cloudfoundryapplication.
To avoid a user-provided bean named corsConfigurationSource from
accidentally preventing access to /cloudfoundryapplication, we now
explicitly configure the filter chain's CORS support to use the same
CorsConfigurationSource as the handler mapping.
Fixes gh-50254
Phillip Webb
Sebastien Tardif
Stéphane Nicoll
Vedran Pavic
Daeho Kwon
Misagh Moayyed
Andy Wilkinson
Manu Sridharan
Lee JiWon