java/ssrf: allowlist guard not recognized when expressed via Stream/lambda (anyMatch), only via plain equals()/for-loop

Commencez par la requête java/ssrf et la bibliothèque partagée sanitizer-guard qu’elle utilise ; examinez comment les formes existantes de equals() et de boucles sont modélisées. Ajoutez une couverture de régression pour les exemples Arrays.stream(...).anyMatch(...), method-reference et contains(...), et vérifiez que les vérifications d’allowlist reconnues effacent l’alerte SSRF sans affaiblir les autres cas.

Query

java/ssrf (Server-side request forgery), Java/Kotlin Security/CWE-918

Summary

The SSRF sanitizer-guard recognition for this query does not appear to model an allowlist check expressed via Arrays.stream(...).anyMatch(...) (or other Stream/lambda/method-reference based equality checks) as taint-clearing, even though a functionally identical check written as a plain for loop with .equals()/.equalsIgnoreCase() calls is recognized and clears the alert.

Example (not recognized — alert fires)

private static boolean isAllowedHost(String host, String... allowedHosts) {
    return Arrays.stream(allowedHosts).anyMatch(host::equalsIgnoreCase);
}

void fetch(String userUrl) {
    URI uri = new URI(userUrl);
    if (isAllowedHost(uri.getHost(), "example.com")) {
        uri.toURL().openConnection(); // still flagged as SSRF sink
    }
}

Example (recognized — alert clears)

private static boolean isAllowedHost(String host, String... allowedHosts) {
    for (String allowed : allowedHosts) {
        if (allowed.equalsIgnoreCase(host)) {
            return true;
        }
    }
    return false;
}

(Identical behavior/contract; only the loop construct differs.)

Why this matters

Lambda-based and Stream-based collection idioms (anyMatch, Set.of(...).contains(...), etc.) have been idiomatic, widely-used Java since Java 8 (2014). A sanitizer-guard recognizer that only matches a narrow inline if (LITERAL.equals(x))/plain-loop shape — and not equivalent Stream/lambda forms — produces false positives that push teams toward less readable, less idiomatic code purely to satisfy the analyzer, with no corresponding security benefit. This also seems inconsistent with sanitizer/guard modeling in other CodeQL queries that do recognize Collection.contains(...)-style checks.

Ask

Could the java/ssrf (and ideally the shared sanitizer-guard library used across similar taint-tracking queries) be extended to recognize equality-based allowlist checks expressed via common Stream/lambda idioms (Arrays.stream(...).anyMatch(x::equals), Collection.contains(x), Set.of(...).contains(x)) as taint-clearing guards, equivalent to their imperative-loop counterparts?

Happy to provide a minimal reproducible test case/repo if useful.