Disabling external entities XML parser is the only guaranteed defense against XXE attacks. Major security standards all agree. But many modern applications still parse untrusted XML with unsafe, default settings. This lets attackers steal server files, probe internal networks, or cause crashes.
The solution isn’t input filtering. it’s configuring the parser correctly. The rest of this guide shows you how to lock it down in every major language, sidestepping the pitfalls that trip up even seasoned engineers. Secure Coding Practices demand it. See the exact steps below.
XML Parser Lockdown: Essential XXE Defense Recap
Secure XML processing. Disable unneeded parser features. Harden configurations. Review all XML-handling components.
- Disable DTDs. This is your best defense. It turns off the entire attack surface.
- Configure your parser library. Safe defaults are uncommon. Java’s
DocumentBuilderFactoryis often vulnerable. - Apply defenses outside your code. Audit third-party libraries. Check file upload processors. They may parse XML internally.
Why Can’t You Trust Default XML Parser Settings?
Default XML parsers are built for standards, not security. Their defaults are dangerous. Java’s DocumentBuilderFactory, for instance, will fetch external entities unless you explicitly stop it. This isn’t a bug, it’s a feature that creates huge risk.
We’ve seen the community fatigue firsthand. Senior engineers call XML a “cheap DSL,” tired of the same old vulnerabilities. Securing a parser often means disabling core parts of its spec. You’re not just flipping a switch; you’re surgically removing functionality to survive a hostile environment.
Blaming developers for forgetting a setting misses the point. The legacy specification is the problem. Input validation, like stripping <!DOCTYPE>, is unreliable. Attackers hide payloads in SVGs, Excel files, or encoded streams. The parser sees it all. The only fix is parser configuration.
Here is our non-negotiable starting point for any parser handling untrusted data:
- Disallow Document Type Declarations (DTDs) entirely, if possible.
- Disable external general entities.
- Disable external parameter entities.
- Disable the loading of external DTDs.
- Set an EntityResolver that returns an empty stream.
These steps form the bedrock of XXE prevention.
How Can You Secure a Java XML Parser Against XXE?
Credits: Hacksplaining
Securing a Java XML parser is verbose and explicit. You have to lock it down line by line. The OWASP Cheat Sheet is essential.
For DocumentBuilderFactory, the best approach is to disable DOCTYPEs completely. This one line stops most attacks.
String FEATURE = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(FEATURE, true);If you need DTDs for validation, you take the longer path. Disable external general entities, external parameter entities, and external DTD loading individually. Also call setXIncludeAware(false) and setExpandEntityReferences(false). Wrap each setFeature call in its own try-catch block. We’ve seen parsers fail silently if a feature isn’t supported.
For XMLInputFactory in StAX parsing, set XMLInputFactory.SUPPORT_DTD to false. Then set the property “javax.xml.stream.isSupportingExternalEntities” to false as well. Don’t assume one setting covers the other.
The FEATURE_SECURE_PROCESSING flag helps, but it’s unreliable on its own. Its behavior changes between implementations. In one of our tests, a parser with only this flag set still fell to a billion laughs. Use it with the specific settings, not instead of them.
How Do You Secure XML Parsers in .NET, PHP, and Python?
The approach changes with each language.
In modern .NET (Core, 5+), XmlReaderSettings defaults to DtdProcessing.Prohibit. That’s good. But legacy .NET Framework or XmlDocument classes are still dangerous. For XmlDocument, you must explicitly set the XmlResolver to null. We’ve seen this single line missed in production audits.
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.XmlResolver = null; // Critical for older .NETPHP’s situation improved with version 8.0, where libxml disables external entities by default. For older versions, you must call libxml_disable_entity_loader(true). Watch out for constants like LIBXML_NOENT, it can expand entities, which is the exact opposite of what you need for security.
Python offers options. xml.etree.ElementTree is generally safe, as it doesn’t process external entities. The popular lxml library is not safe by default. You must create a custom parser:
parser = etree.XMLParser(resolve_entities=False, no_network=True)
Our standard advice is to use the defusedxml package. It’s a secure, drop-in replacement for the standard modules that proactively blocks these attacks.
How Can Dependencies and File Uploads Introduce XXE Risks?
As highlighted by OWASP
“Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations” – OWASP
Hidden XXE Entry Points Beyond Your Application Code
| Source of Risk | How XXE Can Be Triggered | Recommended Defense |
| Third-Party Libraries | Internal XML parsers may process untrusted XML with insecure settings. | Maintain an SBOM and scan dependencies regularly. |
| SVG File Uploads | SVG files contain XML that can be parsed by image-processing tools. | Validate file types and secure all XML-capable processors. |
| Document Processors | PDF, Office, or metadata extraction tools may parse embedded XML. | Audit XML handling throughout the upload pipeline. |
How Do You Build a Layered Defense for XML Processing?
Parser configuration is a primary XXE mitigation. It’s the reinforced door. But security in depth means building walls around it too. Start with the parser lockdown. That’s your base. Then, add input validation as a coarse filter. It won’t catch everything, but it can catch simple, obvious payloads.
Implement strict network egress controls. If a parser is misconfigured, firewall rules can prevent it from calling out to the internet or to sensitive internal segments.
Data from OWASP demonstrates
“SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations.” – OWASP
Finally, integrate XXE testing into your lifecycle. Use SAST tools that can spot insecure parser configurations. Use SCA tools to flag vulnerable library versions. Run DAST scans that include XXE payloads in their tests. Make “disable external entities” a non-negotiable item in your code review checklist for any PR that touches XML parsing.
FAQs
How does disabling external entities improve secure XML parsing?
Disable external entities. This stops parsers from getting files or URLs. It prevents external entity injection. This reduces XXE risks.
Should I disable DTD processing for every XML document?
You should disable DTD processing unless your application specifically requires DTD functionality. Keeping DTD disabled helps prevent entity expansion attacks, strengthens XML hardening efforts, and reduces the XML attack surface available to attackers.
Can XML schema validation replace XXE mitigation controls?
XML schema validation doesn’t stop XXE. It checks document structure, not parser behavior. Secure parser settings are crucial. Disable entity resolution. Configure security features properly.
What causes an XML security misconfiguration in production systems?
XML security misconfigurations happen. Developers use insecure defaults. They don’t review parser features. Incomplete parser configurations risk attacks. They can lead to data disclosure.
How can teams parse untrusted XML safely?
Teams can parse untrusted XML safely by using a safe XML processor with external general entities disabled and external parameter entities disabled. XML input sanitization and XML resolver restrictions provide additional XML processing protection.
Make Secure XML Parsing a Standard Practice
XXE defense doesn’t end when you disable external entities. You still need to verify parser settings, review dependencies, and check how XML is handled across your application. Small gaps can lead to serious exposure. If you want practical, hands-on training that helps developers build safer code from day one, join the Secure Coding Practices Bootcamp here: Join the Bootcamp.
References
- https://wiki.owasp.org/index.php?title=Top_10-2017_A4-XML_External_Entities_(XXE)&printable=yes
- https://owasp.org/www-project-top-ten/2017/A4_2017-XML_External_Entities_(XXE).html