flawopen.com/XXE/Java XML Parser Security
Java XXE: Is DocumentBuilderFactory secure by default?
The JDK enables some secure-processing limits by default, but its default DOM and SAX configuration does not block external resource access. An XML document can therefore trigger file or network access unless the application explicitly restricts it. Behavior can also vary when a third-party JAXP provider replaces the built-in parser. Configure the parser you actually instantiate; do not infer safety from the Java version alone.
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
DocumentBuilder builder =
factory.newDocumentBuilder();
Document document = builder.parse(untrustedXml);
// Risk: parser defaults may allow external
// DTD/entity access and network retrieval.
// Never test with real local files or services.
DocumentBuilderFactory factory =
DocumentBuilderFactory.newDefaultInstance();
// Java 9+: explicitly enable JAXP restrictions.
factory.setFeature(
XMLConstants.FEATURE_SECURE_PROCESSING, true);
factory.setFeature(
"http://apache.org/xml/features/"
+ "disallow-doctype-decl", true);
factory.setAttribute(
XMLConstants.ACCESS_EXTERNAL_DTD, "");
factory.setXIncludeAware(false);
// If a required setting is unsupported, fail closed.
DocumentBuilder builder = factory.newDocumentBuilder();
Document document = builder.parse(untrustedXml);
Why rejecting DOCTYPE is the preferred DOM control
When the parser supports it, rejecting DOCTYPE prevents DTD-defined external entities and entity declarations from being processed. Set FEATURE_SECURE_PROCESSING explicitly and restrict external DTD access as defense in depth; the JDK’s default-on FSP does not mean external connections are denied. Keep XInclude disabled unless required. A provider that rejects a required setting must cause parser initialization to fail rather than silently continue with partial hardening.
If the application must accept DTDs, do not enable external access. Disable external general and parameter entities and external DTD loading, set ACCESS_EXTERNAL_DTD to an empty string, keep processing limits, and disable XInclude unless needed. setExpandEntityReferences(false) changes the document tree representation; it is not a substitute for blocking external resources.
Harden each JAXP processor separately
The same policy applies across XML processing, but the controls differ by API. Review SAXParserFactory/XMLReader, StAX XMLInputFactory, TransformerFactory, SchemaFactory, Validator, and JAXB unmarshalling. StAX does not support FEATURE_SECURE_PROCESSING; disable DTD processing and external entities with its own properties. Also restrict external schema and stylesheet access. Use the OWASP API-specific examples and verify which provider is active.
Do not treat one parser’s settings as global JVM protection. The parser factory selected by JAXP provider lookup may differ from the built-in JDK implementation, and a composite processor may create internal parsers. Test the exact runtime, provider, and code path used in production.
FAQ
Not when it is merely enabled by default. Oracle documents that default-on FSP applies processing limits, while external connections remain allowed unless FSP is explicitly enabled through the API or external access properties are set. Set the policy explicitly and verify your provider.
JDK releases have added restrictions and processing limits, but the Oracle JAXP guide still distinguishes default-on FSP from explicit external-access denial. Third-party providers can also differ. Set the required controls explicitly rather than depending on a version or classpath default.
Use a trusted local catalog or resolver when practical. If DTD processing is necessary, block external protocols and external entity loading, retain JAXP processing limits, and disable XInclude unless needed. This is a more complex policy than rejecting DOCTYPE; test it against the exact provider and legitimate documents.