Should `java/trust-boundary-violation` recognize regex validation guards?

[MarkLee131]

Description of the false positive

The query only recognizes OWASP ESAPI validators as sanitizers. ESAPI is rare in modern Java; most Spring/Jakarta applications validate via String.matches() or @javax.validation.constraints.Pattern instead.

The query treats ESAPI's isValidInput() as sufficient validation, which does the same kind of format checking. So there seems to be an inconsistency in what counts as "validated".

I realize RegexpCheckBarrier is intentionally overapproximate (it doesn't reason about the regex itself), so blindly adding it might be too permissive. But the same applies to ESAPI validators, which also accept arbitrary validation rules.

A few options:

1. Add RegexpCheckBarrier as-is (consistent with how java/ssrf already uses it)
2. Only recognize @Pattern annotations (more conservative)
3. Leave as-is if the overapproximation risk is considered too high

I put together an experimental fix using option 1: https://github.com/MarkLee131/codeql/tree/fix/trust-boundary-regexp-barrier

Curious what the team thinks is the right tradeoff here.

Code samples or links to source code

String input = request.getParameter("input");
if (input.matches("[a-zA-Z0-9]+")) {
    // Validated against a strict regex, but still flagged
    request.getSession().setAttribute("input", input);
}

[MarkLee131]

Opened a PR #21656 for the experimental fix. Hope it helps.