Harden the XPath InputSource evaluation surface

[ppkarwasz]

Hardens the document parse behind the InputSource-taking XPath evaluation entry points.

Problem

FEATURE_SECURE_PROCESSING on an XPathFactory governs only the XPath engine. The stock JDK and Apache Xalan implement XPath.evaluate(String, InputSource) and XPathExpression.evaluate(InputSource) by provisioning an internal document parser the feature does not reach, so external references inside the evaluated document were resolved at that parser's defaults. The library's own DocumentBuilder/SAXParser refuse the identical document.

Changes

XPathHardener's generic branch now returns a HardeningXPathFactory instead of the bare factory (the Saxon branch is unchanged: SaxonProvider's Configuration.makeParser already hardens Saxon's document builds):

• HardeningXPathFactory wraps newXPath() in a HardeningXPath, delegating everything else raw.
• HardeningXPath performs the document build behind evaluate(String, InputSource[, QName]) itself, through a hardened, namespace-aware DocumentBuilder, and evaluates the delegate against the parsed Document, so the engine's own parser never runs. An external reference inside the document resolves to empty on the resolver floor, like every other hardened parse. compile(String) wraps the compiled expression in a HardeningXPathExpression, which applies the same rewrite to evaluate(InputSource[, QName]). The evaluateExpression default methods added by Java 9 route through the overridden overloads, so the Java 8 build stays covered on newer runtimes.

The newXPathFactory() javadoc documents the covered entry points, and the threat model's Scope and intended use enumeration gains XPath objects (the report's tmd-2 correction).

Tests

New XPathInputSourceTest, tagged xpath, which populates the previously empty xpath surefire group; it runs under test-stockjdk, test-xalan and test-xalan-xerces (Saxon's separate path is covered by SaxonXPathExternalCallsTest under xpath3):

• blocks-or-does-not-leak assertions for XPath.evaluate and the compiled XPathExpression.evaluate over a document whose external entity would otherwise surface in the result;
• a positive control evaluating an entity-free document end to end through the hardened pre-parse;
• a leak control proving the unconfigured engine resolves the entity, which also verified the new tests discriminate: with the wrapper removed, both hardened tests fail on all three executions.

ShadingFootprintTest expectations updated: the XPath closure gains the three wrappers plus the DOM hardener set it now parses through, and the whole-library count moves from 29 to 32.

Full mvn clean and plain mvn (checkstyle, spotbugs, pmd, javadoc, and the whole surefire matrix) green, plus a post-build non-vacuous spotbugs:check.

🤖 Generated with Claude Code

[garydgregory]

Hi @ppkarwasz
Please see my comments.
Thank you!

[garydgregory]

Same as before and in other PRs: if there a is a non-deterministic failure, add a clearer comment explaining when it can happen; if it’s an invariant, use assertThrows() instead of using try with an empty catch.

[ppkarwasz]

Applying the same analysis as in #42: I probed every combination that runs these tests (JDK 8–25 × the stock JDK and Xalan XPath engines, over both DOM parsers) and the hardened evaluation never throws — the entity is declared in the internal subset, so the floor only resolves its external content to an empty stream, a legal empty replacement text no parser can reject. Since not throwing is the invariant, c55c682 drops the tolerant try/catch and asserts the strict no-throw/no-leak outcome with assertDoesNotThrow.