On Thu, Dec 18, 2025, 12:37 Elliotte Rusty Harold <[email protected]> wrote:
> I'm not sure what is needed for XPathFactory. I've never seen any > issue involving that. This is the sort of question a detailed proposal > could answer. > We've already had to deal with this exact issue in Commons Text because enabling secure processing for document parsing is separate from enabling it for XPath evaluation. Piotr and I took a deep dive into this topic which then engendered the idea for this new component. HTH, Gary > On Thu, Dec 18, 2025 at 1:35 PM Piotr P. Karwasz > <[email protected]> wrote: > > > > Hi all, > > > > Given the recent surge in low-quality XXE security reports on the one > > hand, and the emergence of CVEs such as CVE-2025-54988 in Apache Tika > > on the other [1], I would like to propose a new Apache Commons project: > > > > Commons JAXP > > > > The initial scope would be deliberately narrow: to provide builders > > that securely configure, in an implementation-independent manner, the > > following Java API for XML Processing (JAXP) factories: > > > > - DocumentBuilderFactory (DOM) > > - SAXParserFactory (SAX) > > - XMLInputFactory (StAX) > > - TransformerFactory (TraX) > > - XPathFactory (XPath) > > > > It seems unreasonable that in 2025 developers are still expected to > > manually apply the same sets of configuration flags copied from > > cheat sheets (such as OWASP [2]), which have effectively been outdated > > for more than a decade. > > > > In 2013, JEP 185 [3] introduced a set of system properties that define > > the allowlist of protocols JAXP implementations may use to retrieve > > external resources. For the default JDK implementations, these lists > > are effectively empty for DOM and SAX (and, somewhat unexpectedly, > > set to "all" for StAX). > > > > However, introducing an older or alternative JAXP implementation on > > the classpath (for example, Xerces) bypasses these safeguards and > > reintroduces the very issues developers believe they are protected > > against. > > > > A small, focused library could address this by: > > > > - Eliminating widespread duplication of JAXP hardening code across > > countless libraries and applications. > > - Providing a single, well-understood location for handling XXE > > concerns, so that any future reports are directed at Commons JAXP > > rather than hundreds of downstream projects. > > > > What do you think? > > > > Piotr > > > > [1] https://www.cve.org/CVERecord?id=CVE-2025-54988 > > [2] > > > https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#java > > [3] https://openjdk.org/jeps/185 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- > Elliotte Rusty Harold > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
