ssrf-guard

Changelog

All notable changes to ssrf-guard are recorded here.

The format follows Keep a Changelog and the project adheres to Semantic Versioning.

[Unreleased]

[3.0.1] — Fix metrics bean classpath gate

Fixed

Migration

Drop in v3.0.1 — no consumer code changes. If you previously worked around the v3.0.0 bug by adding io.micrometer:micrometer-core to your build only because of this error (not because you actually wanted metrics), the dep can come out now.

[3.0.0] — Multi-module + LLM agent SSRF defense

The v2.0.0 starter was a single jar that only worked with Spring’s RestClient. v3.0.0 splits the codebase along client boundaries, adds support for every common JVM HTTP stack, and ships a Spring AI Tool wrapper that closes the SSRF surface LLM agents have been introducing for the last two years.

Added — new modules (opt-in)

Module Use case
ssrf-guard-core Policy / NetUtil / Micrometer metrics interface — no Spring dependency
ssrf-guard-httpclient5 Apache HttpClient 5 DnsResolver + RedirectStrategy (TOCTOU closure)
ssrf-guard-restclient Spring 6.1+ RestClient autoconfig (the v2.0.0 surface, now its own module)
ssrf-guard-resttemplate NEW — Spring RestTemplate autoconfig for the enterprise/legacy crowd
ssrf-guard-webclient NEW — Spring WebFlux WebClient ExchangeFilterFunction + autoconfig
ssrf-guard-feign NEW — Spring Cloud OpenFeign RequestInterceptor + autoconfig
ssrf-guard-springai NEW — Spring AI ToolCallback wrapper that validates URL-shaped tool arguments before LLM-driven execution. The hot SSRF surface in 2025+
ssrf-guard-jdkhttp NEW — java.net.http.HttpClient wrapper (no Spring, JDK 11+)
ssrf-guard-okhttp NEW — OkHttp Interceptor + Dns (no Spring)
ssrf-guard Meta artifact — bundles -core + -httpclient5 + -restclient for v2.0.0 back-compat

Added — defense-in-depth hardening

Added — observability

Changed — BREAKING

Migration

For most consumers, update the version and rebuild — that’s it:

<dependency>
    <groupId>kr.devslab</groupId>
    <artifactId>ssrf-guard</artifactId>
    <version>3.0.0</version>
</dependency>

The ssrf-guard meta artifact transitively pulls in -core, -httpclient5, and -restclient, which together provide the entire v2.0.0 surface.

If you use a different HTTP client, pick the matching module:

<!-- RestTemplate -->
<dependency>
    <groupId>kr.devslab</groupId>
    <artifactId>ssrf-guard-resttemplate</artifactId>
    <version>3.0.0</version>
</dependency>

<!-- WebClient -->
<dependency>
    <groupId>kr.devslab</groupId>
    <artifactId>ssrf-guard-webclient</artifactId>
    <version>3.0.0</version>
</dependency>

<!-- Spring AI tool calls -->
<dependency>
    <groupId>kr.devslab</groupId>
    <artifactId>ssrf-guard-springai</artifactId>
    <version>3.0.0</version>
</dependency>

If your code catches SecurityException from outbound calls, it still works — SsrfGuardException extends SecurityException. If you want the structured tag, catch SsrfGuardException and inspect e.reason().

[2.0.0] — Rebrand to kr.devslab:ssrf-guard

Changed

Added

Migration

Update your dependency coordinate and any direct imports:

<!-- v1.x (never on Maven Central) -->
<dependency>
    <groupId>com.devs.lab</groupId>
    <artifactId>ssrf-guard-spring-boot-starter</artifactId>
    <version>1.1.0</version>
</dependency>

<!-- v2.0.0 -->
<dependency>
    <groupId>kr.devslab</groupId>
    <artifactId>ssrf-guard</artifactId>
    <version>2.0.0</version>
</dependency>

application.yml keys are unchanged — ssrf.guard.* works identically.

Direct imports of the security types? Replace devs.lab.ssrf with kr.devslab.ssrfguard and split between kr.devslab.ssrfguard.autoconfigure (properties + auto-config) and kr.devslab.ssrfguard.security (interceptor + resolver + redirect + NetUtil).

[1.1.0] — 2025-09-23

semantic-release rollup of pre-v2 work. Tagged but never published to Maven Central.

[1.0.0] — 2025-09-23

Initial public release. Tagged but never published to Maven Central.

This site is open source. Improve this page.