Fix open redirects in Java and Spring Boot

1. Find every redirect built from request data: return "redirect:" + param, new RedirectView(param), new ModelAndView("redirect:" + param), response.sendRedirect(param), ResponseEntity.status(...).location(...), and Spring Security success handlers configured with setTargetUrlParameter or setUseReferer.
2. Refuse a value that contains a backslash or an ASCII control character: browsers read \ as / and drop tabs and newlines, and java.net.URI does neither (it throws on most of them).
3. Parse with new URI(next) and treat URISyntaxException as a refusal. With no scheme and no authority the value is a path: accept it only if it starts with exactly one slash, because URI reports no authority for ///evil.example/.
4. Otherwise require scheme https, a host in an exact allowlist (compared in lower case), port -1 and no user info.
5. Return "redirect:" + the value you checked, and "redirect:/account" on any refusal; @RequestParam(defaultValue = "/account") covers a missing or empty next.
6. With Spring Security form login, rely on its RequestCache instead of a parameter: the default success handler returns users to the request it saved in the session.
7. Add regression tests that sign in through MockMvc with this card's payloads and resolve the Location header the way a browser does (the BrowserUrl helper in the tests).

The three implementations share one API and one test suite; only the code below changes. The tests load the one that IMPL names.

@Override
public String redirectAfterLogin(String next) {
    return "redirect:" + next;
}

private static final Set<String> ALLOWED_HOSTS = Set.of("app.example.test", "docs.example.test");
private static final String FALLBACK = "/account";

@Override
public String redirectAfterLogin(String next) {
    return "redirect:" + safeRedirectTarget(next);
}

static String safeRedirectTarget(String next) {
    // Browsers read "\" as "/" and drop tabs and newlines. Refuse them here rather than rely on
    // java.net.URI happening to throw on them.
    if (next.indexOf('\\') >= 0 || next.chars().anyMatch(c -> c < 0x20 || c == 0x7f)) {
        return FALLBACK;
    }
    URI uri;
    try {
        uri = new URI(next); // also rejects spaces, braces and other characters a URI cannot contain
    } catch (URISyntaxException e) {
        return FALLBACK;
    }
    if (uri.getScheme() == null && uri.getRawAuthority() == null) {
        // A path on this site. URI finds no authority in ///evil.example/, so check the slashes too.
        return next.startsWith("/") && !next.startsWith("//") ? next : FALLBACK;
    }
    boolean allowed = "https".equalsIgnoreCase(uri.getScheme())
            && uri.getHost() != null
            && ALLOWED_HOSTS.contains(uri.getHost().toLowerCase(Locale.ROOT))
            && uri.getPort() == -1
            && uri.getRawUserInfo() == null;
    return allowed ? next : FALLBACK;
}

@Override
public String redirectAfterLogin(String next) {
    return "redirect:" + checkedTarget(next);
}

private static String checkedTarget(String next) {
    // A path on this site...
    if (next.startsWith("/")) {
        return next;
    }
    // ...or a full link back to one of our sites, app.example.test or docs.example.test.
    try {
        String host = new URI(next).getHost();
        if (host != null && host.contains("example.test")) {
            return next;
        }
    } catch (URISyntaxException e) {
        // not a valid URI
    }
    return "/account";
}

The exploit tests send the attack and check that it fails; functional tests next to them keep ordinary requests working, so a fix that rejects everything fails too.

/**
 * Each value arrives in a link to the real sign-in page, such as /login?next=%2F%2Fevil.example%2F.
 * After a genuine sign-in the browser must still be on this site or the allowlisted docs site.
 */
class ExploitTest extends LoginFlow {

    @Test
    void anAbsoluteUrlToAnotherSite() throws Exception {
        assertLandsOnAnAllowedSite("https://evil.example/");
    }

    @Test
    void aSchemeRelativeUrl() throws Exception {
        assertLandsOnAnAllowedSite("//evil.example/");
    }

    @Test
    void threeSlashes() throws Exception {
        assertLandsOnAnAllowedSite("///evil.example/");
    }

    @Test
    void aBackslashAfterTheSlash() throws Exception {
        assertLandsOnAnAllowedSite("/\\evil.example/");
    }

    @Test
    void twoBackslashes() throws Exception {
        assertLandsOnAnAllowedSite("\\\\evil.example/");
    }

    @Test
    void ourHostNameAsAUserName() throws Exception {
        assertLandsOnAnAllowedSite("https://app.example.test@evil.example/");
    }

    @Test
    void aLookAlikeHostThatContainsAnAllowedName() throws Exception {
        assertLandsOnAnAllowedSite("https://docs.example.test.evil.example/");
    }

    @Test
    void aBackslashBeforeTheAt() throws Exception {
        assertLandsOnAnAllowedSite("https://evil.example\\@docs.example.test/");
    }

    @Test
    void encodedSlashes() throws Exception {
        assertLandsOnAnAllowedSite("/%2F%2Fevil.example/");
    }

    @Test
    void aJavascriptUrl() throws Exception {
        assertLandsOnAnAllowedSite("javascript:alert(document.domain)");
    }
}

• java.net.URI reports no host for ///evil.example/ and throws on /\evil.example/, and UriComponentsBuilder's default parser reports no host for either; a check that treats 'no host' as 'local' approves both, and browsers go to evil.example.
• UriComponentsBuilder.fromUriString(next, ParserType.WHAT_WG) is documented as aligning with how browsers parse URLs, but it parses relative input against an empty base: on Spring Framework 7.0.9 it returned no host for /\evil.example/, \\evil.example/ and ///evil.example/, which a browser on an https page sends to evil.example.
• Spring Framework fixed three host-validation bypasses in UriComponentsBuilder in 2024 (CVE-2024-22243, CVE-2024-22259, CVE-2024-22262): applications that parsed an external URL and checked its host could be steered into an open redirect or SSRF. Refusing ambiguous characters before parsing narrows that kind of parser gap.
• Spring Security's AbstractAuthenticationTargetUrlRequestHandler returns the targetUrlParameter value, and the Referer header when useReferer is set, without checking it (Spring Security 7.1.1), so setTargetUrlParameter("next") turns form login into an open redirect.
• startsWith("/") accepts //evil.example/ and /\evil.example/; a host test with contains or endsWith accepts docs.example.test.evil.example and look-alike registrations. Compare whole hosts against a set.
• Browsers refuse a Location header whose scheme is not http or https, but a javascript: value rendered into an href runs as script; keep the scheme check wherever next is used.
• Semgrep's Spring rule matches only a method whose whole body is return "redirect:" + param, and CodeQL's default Java query does not model "redirect:" view names at all; keep the regression tests.

1. Run the tests in all three modes: IMPL=fixed must pass; IMPL=vulnerable and IMPL=wrong must fail (node ../../run-all.mjs open-redirect/java-spring does this for you).
2. Against your own app, sign in through /login?next=%2F%5Cevil.example%2F and /login?next=%2F%2F%2Fevil.example%2F and check that the Location header resolves to your own origin in a browser, not just in java.net.URI.
3. Semgrep's Spring rule flags only the exact return "redirect:" + param shape; review every "redirect:", RedirectView, sendRedirect and Location header by hand or with the experimental CodeQL query.

What each rule reported when it was run on this card's code, or what its source shows it covers where it was not run. A rule that exists for the weakness does not always catch it.

Download the project, install its dependencies once (this step needs the network), then run the tests against each implementation from the open-redirect/java-springfolder. Maven runs with JDK 21 (set JAVA_HOME).

mvn -B -q test

# Expected: every test passes
IMPL=fixed mvn -B -o -q test

# Expected: an exploit test fails
IMPL=vulnerable mvn -B -o -q test

# Expected: a test fails
IMPL=wrong mvn -B -o -q test

Each run writes a JUnit report to target/surefire-reports/TEST-*.xml. From the top folder of the download, node run-all.mjs open-redirect/java-spring runs all three modes and checks the expected results.

Download the project ZIP, 26 KB

Verified

Machine

macOS 27.0 (Darwin 27.0.0, arm64)

Toolchain

• jdk OpenJDK 21.0.12.1
• maven 3.9.16
• springBoot 4.1.1
• springFramework 7.0.9
• tomcat 11.0.26
• jackson 3.1.7
• junitJupiter 6.0.3
• semgrep 1.180.0

Matrix

fixed: 16 of 16 tests pass; vulnerable: 9 of 16 tests fail (9 exploit tests); wrong: 4 of 16 tests fail (4 exploit tests)

Test results

fixed 16/16 pass; vulnerable 9/16 fail (9 exploit tests: every payload except the encoded slashes); wrong 4/16 fail (4 exploit tests: //, ///, /\ and the look-alike host), offline after install

Dependency freshness

Spring Boot 4.1.1 was published on 2026-08-20. Boot 4.1.1 manages Tomcat 11.0.24 and Jackson 3.1.5, which have advisories fixed in Tomcat 11.0.26 and Jackson 3.1.7, so the pom overrides tomcat.version to 11.0.26 (2026-09-09) and jackson-bom.version to 3.1.7 (2026-09-21), as the other Java cards do. OSV listed no advisories for the 72 resolved artifacts on 2026-10-10. Maven has no lockfile; the Boot parent and the two overrides fix every version. .mvn/maven.config pins the file-lock sync context because several agents run Maven at once.

Versions and results hold for the toolchain above. The card's tests are the check: run them with your own versions before relying on the fix.

References

1. OWASP Unvalidated Redirects and Forwards Cheat Sheet
2. Java SE 21: java.net.URI
3. Spring Framework: URI parsing (RFC and WhatWG parser types)
4. Spring MVC: handler method return values (redirect: view names)
5. CVE-2024-22262: Spring Framework URL Parsing with Host Validation (3rd report)
6. Spring Security: form login (saved request and success handler)
7. CodeQL query help: java/unvalidated-url-redirection
8. CWE-601: URL Redirection to Untrusted Site ('Open Redirect')