Spring Boot 4.1: Native gRPC, SSRF Mitigation, and What to Upgrade Now

Spring Boot 4.1 dropped on June 10 and finally makes gRPC a first-class citizen. After years of leaning on a community-maintained starter that the Spring team did not own and did not guarantee, gRPC support is now built directly into the framework. That is the headline, but 4.1 also ships built-in SSRF mitigation for HTTP clients and bumps the Kotlin baseline to 2.3. Here is what each of these means for your codebase.

gRPC Is Now First-Class

The story here is straightforward: Spring Boot 4.1 co-releases with Spring gRPC 1.1.0 and ships three dedicated starters that wire into the framework exactly like JPA or Redis do today. Health indicators, observability hooks, Spring Security integration, and exception handling are all included automatically.

Quarkus has had first-class gRPC since 2021. Micronaut since 2020. Spring Boot teams either lived without gRPC or relied on the net.devh:grpc-spring-boot-starter community library — functional, but unsupported by the Spring team and absent from official docs. That changes with 4.1.

There are three starters. Add the one you need:

<!-- Server -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-grpc-server</artifactId>
</dependency>

<!-- Client -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-grpc-client</artifactId>
</dependency>

<!-- Testing -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-grpc-test</artifactId>
  <scope>test</scope>
</dependency>

The server defaults to port 9090 on a Netty transport. If your service needs to serve gRPC and REST on the same port, switch to Servlet mode with HTTP/2 on Tomcat or Jetty. On the client side, @ImportGrpcClients auto-wires your stubs — no boilerplate. For exception handling, @GrpcAdvice works exactly like @ControllerAdvice, so there is nothing new to learn. Tests get @AutoConfigureTestGrpcTransport, which spins up an in-process channel with zero network configuration.

spring:
  grpc:
    server:
      port: 9090

SSRF Mitigation: You Must Opt In

SSRF — server-side request forgery — is on the OWASP API Security Top 10 for good reason. An attacker who can influence where your service sends outbound HTTP requests can reach AWS instance metadata endpoints, internal databases, and other microservices that should never be exposed externally. Spring Boot previously gave you no built-in guard against this. Spring Boot 4.1 does.

The new InetAddressFilter sits in front of RestClient, RestTemplate, and WebClient — both reactive and blocking clients auto-configured by Spring Boot. When a request targets a blocked address range, the filter rejects it before the connection is made. The catch: this is opt-in. You must declare it as a bean.

@Bean
public InetAddressFilter ssrfFilter() {
    return InetAddressFilter.denyRanges(
        "10.0.0.0/8",        // RFC 1918
        "172.16.0.0/12",     // RFC 1918
        "192.168.0.0/16",    // RFC 1918
        "169.254.0.0/16"     // AWS metadata endpoint
    );
}

Add this to every service that makes outbound HTTP calls with Spring-managed clients. One important scope note: if you create a custom HttpClient or OkHttpClient bean outside of Spring Boot’s auto-configuration, the filter does not apply. Your custom HTTP clients need their own protection.

Kotlin 2.3 and Removed Baggage

Spring Boot 4.1 moves the Kotlin baseline from 2.2 to 2.3. The practical additions are Java 25 target support and an experimental unused return value checker: annotate a function with @CheckReturnValue and the compiler warns callers who discard the result — useful for functions that return errors rather than throwing them.

Three things were also cleaned up. Apache Derby is deprecated in 4.1 — switch to H2 or HSQL for in-memory testing. The layertools jar mode is gone — if you are still using it for layered Docker images, move to Paketo buildpacks. And in Maven, -DskipTests no longer skips AOT processing; use -Dmaven.test.skip instead. These are not surprises — all three were deprecated in 4.0 — but they will surface as build failures on upgrade if you have not cleared them.

Upgrading From Spring Boot 4.0

This is a minor release. The 4.0 to 4.1 upgrade path is clean — no platform-level changes, no framework renames, no dependency group ID shifts. Remove deprecated Derby dependencies, update Maven flags, and bump the version. The official release notes list every removed deprecated API. The difficult upgrade was 3.x to 4.0. This is not that.

One deadline worth flagging: Spring Boot 3.5 reaches end of life on June 30, 2026. That is nine days from now. If you are on 3.5, you are either upgrading in the next week or accepting that you will run an unsupported version indefinitely. The 4.x upgrade is a bigger project, but 3.5 EOL is not a date to ignore.

The Practical Summary

Spring Boot 4.1 ships three things worth acting on this week: native gRPC starters if you are building or migrating microservices that use it, an SSRF filter you should add to every service making outbound HTTP calls, and a Kotlin 2.3 baseline with Java 25 target support. None of these require a migration project. Bump the version, add the filter bean, swap in the gRPC starters if you need them. The Spring team has made 4.0 to 4.1 as close to a no-op as a minor release can be — no reason to delay.