Understanding and Preventing SSRF in Spring Boot 4.1 with RestClient

What is SSRF ?

SSRF (Serverside Request Forgery) is a security vulnerability that occurs when an application (server side) makes an HTTP request to an URL that's supplied by the user (or by it's client)

At first glance, this may seem harmless. Many applications legitimately allow users to provide URLs : for example, when uploading a product image from an external source.

However, the situation becomes dangerous when the backend server can access resources that the user cannot access directly.

In this article : we will explore SSRF using a hands-on Spring Boot application and demonstrate how Spring Boot 4.1's built-in IP address filtering can help mitigate this vulnerability when using RestClient.

SSRF Demo

In this Spring boot app : https://github.com/arundotin/ssrf-demo

We will implement two API versions:

• V1 API : uses unprotected RestClient
• V2 API : uses protected RestClient

The objective is to understand the vulnerability, reproduce it locally and implement a practical mitigation.

Start this application Locally and try out

This application allows a user to create a product by providing its name, price and image URL

The backend receives a HTTP POST request

POST /api/v1/products
Content-Type: application/json
{
  "name": "Coffee Mug",
  "price": 499.00,
  "imageUrl": "https://example.com/image.png"
}

POST /api/v1/products
Content-Type: application/json
{
  "name": "Coffee Mug",
  "price": 499.00,
  "imageUrl": "https://example.com/image.png"
}

The application then makes an HTTP request to the supplied image URL.

The problem is that the application may not distinguish between a legitimate public URL and a URL that points to an internal resource.

For example:

http://127.0.0.1:8080
http://192.168.1.10
http://169.254.169.254

http://127.0.0.1:8080
http://192.168.1.10
http://169.254.169.254

These destinations may represent:

• The application's own localhost endpoint.
• An internal network service.
• or any sensitive service that this backend has access to.

If the backend is able to access these resources, an attacker may abuse the application as a proxy to reach destinations that would otherwise be inaccessible.

This is the fundamental idea behind SSRF.

V1 API (unprotected RestClient)

The V1 API uses an unprotected RestClient

@Configuration
public class RestClientConfig {

    @Bean
    public RestClient restClient() {
        return RestClient.builder().build();
    }
}

@Configuration
public class RestClientConfig {

    @Bean
    public RestClient restClient() {
        return RestClient.builder().build();
    }
}

and calls the supplied URL inorder to do some sort of verification

See Line Number 31 here

restClient.get()
                .uri(request.imageUrl())
                .retrieve()
                .toBodilessEntity();

restClient.get()
                .uri(request.imageUrl())
                .retrieve()
                .toBodilessEntity();

V2 API uses Spring Boot 4.1 IP filtering

Spring Boot 4.1 introduces InetAddressFilter, which can be configured through the HTTP client settings used by Spring's HTTP client infrastructure.

The filter allows us to control which IP addresses the HTTP client is permitted to connect to.

See Line number 20 to 36 here : configuring IP Filtering

InetAddressFilter.externalAddresses()

InetAddressFilter.externalAddresses()

This filter is intended to allow external, routable destinations while excluding restricted address categories.

Instead of allowing the application to connect to every destination, we can configure a protected HTTP client.

Comparing V1 and V2

V1

The protected HTTP client rejects the destination before establishing the outbound connection. V2 API filters the host before making the outbound connection

This demonstrates the effectiveness of the built-in IP address filtering for the tested localhost scenario.

Is IP filtering enough to prevent SSRF?

IP filtering is an important layer of defense, but SSRF protection should be approached as a defense-in-depth problem.

A few more settings like

• URL Allow-listing
• Redirect Handling
• etc, etc

Can also be enabled to provide stronger SSRF protection

Conclusion

SSRF is a vulnerability that can arise when a backend application makes HTTP requests to user-controlled destinations without sufficient restrictions.

The key takeaway is that a backend HTTP client should not blindly trust a URL supplied by an external user.

Spring Boot 4.1 makes IP-based destination filtering easier to configure, but robust SSRF protection still requires careful handling of URLs, redirects, DNS resolution, and network access.

Thanks

Arun