flawopen.com/XXE/Java DocumentBuilderFactory

Is XXE enabled by default in Java's DocumentBuilderFactory?

CWE-611: Improper Restriction of XML External Entity ReferenceReference page
Short answer

Yes. The JDK's XML parsers process DOCTYPE declarations and resolve external entities unless you turn that off explicitly. This is the single most common source of XXE in Java applications, because the vulnerable configuration is the one you get by writing the obvious three lines.

VULNERABLE — the default
DocumentBuilderFactory dbf =
    DocumentBuilderFactory.newInstance();
DocumentBuilder db =
    dbf.newDocumentBuilder();
Document doc = db.parse(untrustedXml);

// Attacker sends:
// <!DOCTYPE r [
//   <!ENTITY x SYSTEM
//     "file:///etc/passwd"> ]>
// <r>&x;</r>

// → file contents appear in the
//   parsed document, or leak via
//   an out-of-band URL (SSRF).
FIXED
DocumentBuilderFactory dbf =
    DocumentBuilderFactory.newInstance();

// Best single control: no DOCTYPE at all
dbf.setFeature(
  "http://apache.org/xml/features/"
  + "disallow-doctype-decl", true);

// Belt and braces, if DOCTYPE is needed
dbf.setFeature("http://xml.org/sax/"
  + "features/external-general-entities",
  false);
dbf.setFeature("http://xml.org/sax/"
  + "features/external-parameter-entities",
  false);
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

Why "disallow-doctype-decl" is the control to prefer

Setting that one feature to true causes the parser to throw as soon as it encounters a DOCTYPE declaration. Because every XXE variant — file read, SSRF, parameter-entity out-of-band exfiltration, and billion-laughs style expansion denial of service — requires a DOCTYPE, rejecting it closes the whole family at once. The other features are useful defence in depth for the rare case where you must accept a DTD.

Almost no application that parses XML from an external party genuinely needs callers to supply a DTD. If yours does not, disallow it and stop reasoning about the individual entity types.

The same applies to every JDK XML API

This is not specific to DocumentBuilderFactory. SAXParserFactory, XMLInputFactory (StAX), TransformerFactory, SchemaFactory, Validator and XMLReader each need equivalent hardening, with slightly different property names. The OWASP cheat sheet lists the exact incantation per factory and is the practical reference to work from.

Note also that XMLInputFactory uses its own property — XMLInputFactory.SUPPORT_DTD set to false — rather than the Apache feature string.

FAQ

Does FEATURE_SECURE_PROCESSING fix XXE on its own?

Not reliably. XMLConstants.FEATURE_SECURE_PROCESSING imposes limits aimed principally at entity-expansion denial of service, and its precise behaviour has varied across JDK versions and XML implementations. Set it, but set the DOCTYPE control as well rather than relying on it alone.

Have newer JDKs changed the defaults?

Restrictions have tightened over time, and some distributions and frameworks apply their own hardened defaults. Because behaviour depends on the JDK version and the XML implementation actually on the classpath, configure the features explicitly rather than depending on the environment being safe.

What if the parse fails because legitimate documents have a DTD?

Then disable external general and parameter entities and XInclude while permitting the DOCTYPE, and set entity expansion limits. Accepting a DTD from an untrusted source is a meaningfully weaker position, so confirm it is a real requirement first.

References