Team, Great to see this proposal and discussion. Speaking from experience on the Apache NiFi project, having a minimal library that provides safe defaults for XML processing sounds helpful.
Apache NiFi 1.17.0 added [1] an internal module named nifi-xml-processing [2] several years ago to implement a thin wrapper and secure defaults for the various JAXP interfaces. The module includes test cases for common exploitations. One challenge worth noting is that different XML provider implementations may be slightly different in terms of the features and properties they honor. Default behavior has also changed over the course of major Java releases, so that may add some complexity depending on platform versions supported. Regards, David Handermann [1] https://issues.apache.org/jira/browse/NIFI-9901 [2] https://github.com/apache/nifi/tree/main/nifi-commons/nifi-xml-processing On Thu, Dec 18, 2025 at 1:57 PM Romain Manni-Bucau <[email protected]> wrote: > > Hi, > > Since the secure configuration is implementation independent, will the > project just create N modules with one per implementation supported? > What is the plan? > Will it decorate all "factory" and provide its own SPI impl to not create > yet another API? > > The risk is to create something more bothering than helping since it is > literally 7-8 lines to make it fixed and most projects did 7-8 years ago so > wonder the added value today. > > Romain Manni-Bucau > @rmannibucau <https://x.com/rmannibucau> | .NET Blog > <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | > Old > Blog <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> > Javaccino founder (Java/.NET service - contact via linkedin) > > > Le jeu. 18 déc. 2025 à 19:05, Gary Gregory <[email protected]> a > écrit : > > > 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] > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
