XML external entity (XXE) due to external entities enabled in XMLInputFactory

High Risk Application Security
javaxmlxxexmlinputfactoryexternal-entitiesssrf

What it is

XMLInputFactory configurations that allow external entity processing can lead to XML External Entity (XXE) attacks. This vulnerability enables attackers to read local files, perform Server-Side Request Forgery (SSRF), cause denial of service through entity expansion, and potentially execute remote code. XXE attacks exploit the XML parser's ability to process external entities defined in malicious XML documents.

ℹī¸ Configuration Fix

Configuration changes required - see explanation below.

💡 Explanation

ℹī¸ Configuration Fix

Configuration changes required - see explanation below.

💡 Explanation

Why it happens

Java XMLInputFactory instances created using XMLInputFactory.newInstance() default to allowing external entity processing (IS_SUPPORTING_EXTERNAL_ENTITIES = true) and DTD support (SUPPORT_DTD = true). These insecure defaults enable XXE attacks where malicious XML documents can define external entities referencing local files (file:///etc/passwd), internal network resources (http://internal-server/), or remote attacker-controlled servers. Developers unaware of these defaults create vulnerable XML parsers that process untrusted input without security hardening.

Root causes

XMLInputFactory Default Settings Enable External Entities

Java XMLInputFactory instances created using XMLInputFactory.newInstance() default to allowing external entity processing (IS_SUPPORTING_EXTERNAL_ENTITIES = true) and DTD support (SUPPORT_DTD = true). These insecure defaults enable XXE attacks where malicious XML documents can define external entities referencing local files (file:///etc/passwd), internal network resources (http://internal-server/), or remote attacker-controlled servers. Developers unaware of these defaults create vulnerable XML parsers that process untrusted input without security hardening.

Failure to Disable DTD Processing

XML parsers allow Document Type Definition (DTD) processing which enables entity declarations and external entity references. Applications fail to explicitly disable DTD support through factory.setProperty(XMLInputFactory.SUPPORT_DTD, Boolean.FALSE). DTD processing is the primary mechanism for XXE attacks, allowing attackers to declare entities like <!ENTITY xxe SYSTEM "file:///sensitive-data"> and reference them in XML content. Even when external entities are disabled, DTD processing can enable entity expansion denial-of-service attacks.

Lack of XXE Awareness in Development Teams

Developers lack security training on XML External Entity vulnerabilities and don't recognize that XML parsing represents a significant attack surface. Teams treat XML as a simple data format without understanding the security implications of entity processing, DTD declarations, and external references. Code reviews miss XXE vulnerabilities because reviewers don't check XML parser configurations. Legacy code written before XXE became widely understood (pre-2013 OWASP Top 10) continues running with insecure defaults in production systems.

Legacy XML Processing Configurations

Applications use outdated XML processing patterns and libraries from before XXE mitigations became standard. Legacy code bases contain XMLInputFactory usage without security hardening, copied from old tutorials or Stack Overflow answers that predate security awareness. Migration to newer Java versions doesn't automatically fix XXE vulnerabilities in existing code. Organizations running applications on old application servers or using deprecated XML processing libraries inherit insecure default configurations that were acceptable in earlier Java versions.

Processing Untrusted XML Without Security Controls

Applications parse XML from untrusted sources (user uploads, web services, configuration files, API requests) without implementing XXE-specific security controls. Systems accept XML input from external partners, process SOAP messages, parse configuration uploads, or consume RSS/Atom feeds without validating parser security settings. Applications fail to implement defense-in-depth measures like input size limits, content validation, allowlist filtering, or restrictive XMLResolver implementations, relying solely on insecure default parser configurations.

Fixes

1

Disable External Entity Processing in XMLInputFactory

Configure XMLInputFactory to explicitly disable external entity support by calling factory.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, Boolean.FALSE). This prevents the parser from resolving external entity references defined in malicious XML documents, blocking file disclosure and SSRF attacks. Apply this configuration to all XMLInputFactory instances before creating XMLStreamReader objects. Wrap configuration in try-catch blocks to handle potential IllegalArgumentException from parsers that don't support this property. Test that external entity references in XML input are properly rejected.

2

Disable DTD Processing Completely

Set factory.setProperty(XMLInputFactory.SUPPORT_DTD, Boolean.FALSE) to completely disable Document Type Definition processing in the XML parser. DTD disablement prevents both external entity attacks and entity expansion denial-of-service attacks (billion laughs attack). This is the most effective single mitigation for XXE vulnerabilities as it removes the mechanism that enables entity declarations. For parsers that must support DTDs for legitimate use cases, combine with external entity restrictions and implement strict entity expansion limits to prevent abuse.

3

Implement Restrictive XMLResolver for Entity Resolution

Create and register a custom XMLResolver implementation that rejects all external entity resolution attempts: factory.setXMLResolver(new SecureXMLResolver()). Implement the resolver to throw SecurityException for any resolveEntity() calls, preventing fallback entity resolution even if other protections fail. Use this as defense-in-depth alongside disabling external entities. A restrictive resolver provides logging/monitoring of XXE attack attempts, alerting security teams to malicious input. Example: class SecureXMLResolver implements XMLResolver { public Object resolveEntity(...) { throw new SecurityException("External entities blocked"); } }

4

Adopt XML Libraries with Secure Default Configurations

Migrate to modern XML processing libraries that default to secure configurations or provide simplified secure APIs. Use JAXB with hardened configuration, Jackson XML module with XXE protections enabled, or libraries specifically designed for security like owasp-java-xml-security. For new projects, prefer JSON over XML to avoid entire class of XXE vulnerabilities. If XMLInputFactory must be used, create a secure factory builder pattern that encapsulates all security configurations and is used consistently across the application: SecureXMLFactory.createInputFactory() that returns pre-hardened instances.

5

Validate and Sanitize XML Input with Schema Validation

Implement XML Schema (XSD) validation to enforce expected XML structure before parsing with XMLInputFactory. Use factory.setProperty(XMLInputFactory.IS_VALIDATING, Boolean.TRUE) combined with schema validation to reject unexpected elements, attributes, or structures. Validate XML against strict schemas that define allowlisted elements, enforce size limits, and restrict content patterns. Pre-scan XML input for suspicious patterns (<!ENTITY, <!DOCTYPE, SYSTEM, PUBLIC) and reject documents containing these before parser invocation. Implement file size limits (e.g., max 1MB) to prevent denial-of-service through large entity expansion.

6

Implement Input Size and Complexity Limits

Configure entity expansion limits to prevent denial-of-service attacks even when DTDs are allowed. Set JVM properties like -Djdk.xml.entityExpansionLimit=0 to disable entity expansion or set low limits (e.g., 64). Implement application-level checks for XML input size before parsing (reject files > 10MB). Monitor and limit parser memory consumption using Java SecurityManager or resource quotas. Implement timeouts for XML parsing operations to prevent hung parsers from consuming resources indefinitely. Track nesting depth and entity reference counts during parsing to detect billion laughs attacks early.

7

Use Element and Content Allowlisting

Implement strict allowlisting of acceptable XML element names, attributes, and content patterns during parsing. Create a Set of permitted element names and validate each START_ELEMENT event against the allowlist: if (!allowedElements.contains(reader.getLocalName())) throw SecurityException. Reject XML documents containing unexpected elements before processing sensitive data. Validate attribute values and text content against expected patterns (regex validation for emails, numbers, etc.). Combine allowlisting with parser security configuration for defense-in-depth. Log rejected elements for security monitoring and attack pattern analysis.

Detect This Vulnerability in Your Code

Sourcery automatically identifies xml external entity (xxe) due to external entities enabled in xmlinputfactory and many other security issues in your codebase.

Scan Your Code for Free Explore More Vulnerabilities