Disable external entity resolution in your parser to stop XXE attacks. The real problem is making that change without breaking old SOAP services your company still needs. This guide tackles that exact issue, showing you how to tighten security while keeping legacy systems running. You’ll find specific configurations, checks to validate your setup, and a look at the less obvious places XXE can hide.
For anyone serious about Secure Coding Practices, this is your guide to practical XXE mitigation strategies developers guide. Keep reading.
XXE Defense Essentials
These are the core lessons for preventing, validating, and uncovering XML External Entity vulnerabilities across modern applications.
- Disable DTDs and external entities completely in your parser’s configuration, it’s the primary defense.
- Validate your fix with interception tools, don’t just trust that the code change worked.
- Scan for XXE in indirect paths like file metadata and third-party libraries, not just main APIs.
Do Modern Frameworks Automatically Prevent XXE?
It’s easy to get tricked by modern frameworks. You move to the latest .NET Core or PHP 8, see the security patches in the release notes, and assume you’re safe. The parser might be safer out of the box, sure. But then someone adds a flag for a performance tweak, or a third-party library calls an old constructor. Just like that, the safe default is undone.
We’ve seen this firsthand. A PHP 8 app, where external entities are disabled by default, had a LIBXML_NOENT flag slapped onto a DOMDocument load. That flag explicitly tells the parser to expand entities, flipping the safety switch right off. The hole is wide open again.
This is a common pattern. Java’s parsers are notoriously insecure by default, needing specific setFeature calls to lock them down. Older .NET Framework classes, like XmlDocument, required you to set the XmlResolver to null yourself. The security doesn’t come from the framework version number. It comes from your config.
- Java: Needs explicit
setFeaturecalls. - .NET Framework (<4.5.2):
XmlResolverdefaults needed nulling. - PHP: Safe defaults can be overridden by flags.
How Can You Disable External Entities Completely?
The rule is straightforward. If your app has no business processing Document Type Definitions, disable them completely. This XML external entity prevention step blocks most XXE attacks, and the OWASP Cheat Sheet calls it the safest approach. Here’s what that actually looks like across different parsers.
In Java, you’d configure a DocumentBuilderFactory like the example below. Always use a try-catch block, because not every parser supports every feature.
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
try {
// Primary defense: disallow DOCTYPE declarations
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
// Secondary defenses if DTDs are somehow still allowed
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);
} catch (ParserConfigurationException e) {
// Log this; the feature might not be supported
}We apply the same logic everywhere. In .NET, you set DtdProcessing = DtdProcessing.Prohibit on XmlReaderSettings. For Python, you skip the standard xml.etree entirely and use the defusedxml package. In PHP, you make sure LIBXML_NOENT never touches untrusted input. It all comes down to taking direct control of your parser’s configuration.
Can XXE Still Be Exploited After Disabling External Entities?
You disable general external entities and think you’re safe. That’s the classic mistake. XXE isn’t one feature, it’s a cluster of related XML capabilities that can be abused. If you leave parameter entities enabled, an attacker might use them to exfiltrate data. If XInclude processing is on, they might use that path instead. A partial fix creates a dangerous illusion of security.
The defense is to treat parser hardening as a package. You need to disable the whole set:
- External general entities.
- External parameter entities.
- External DTD loading.
- XInclude processing (unless explicitly required).
Missing one is like locking your front door but leaving the back window open. The OWASP guidance is comprehensive for a reason. It lists all the features that need to be turned off across different parsers, like SAXParserFactory and XMLReader. We learned this the hard way on a project years ago, patching one entity type only to get flagged for another in a penetration test. The checklist exists because people forget.
Where Can XXE Hide Outside Traditional XML Endpoints?
Credits: OWASP Portland, Aregon
Your main API doesn’t accept XML. You think you’re fine. But what about that user avatar upload? It expects a JPEG. The library that extracts the caption or geotag might be parsing XMP metadata, which is XML embedded inside the image file. A crafted payload there could trigger an XXE in your image processor.
XXE hides in indirect paths:
- DOCX, ODT, and other office documents (they’re ZIPs containing XML).
- SVG images (they’re literally XML text).
- PDF files that use XML-based metadata or forms.
- Systems that parse sitemaps.xml or RSS feeds in the background.
You have to think about any code that unpacks or inspects files. That background worker pulling a sitemap, the document conversion service, the search indexer that reads metadata. These are all XML ingestion points. They often use default parser settings because the developer wasn’t thinking about security, they were just trying to parse some data.
As highlighted by blackhat.com
“There is lots of surface area for exploitation covering file types including Office Open XML documents, PDFs with XMP metadata, and SVG images” – blackhat.com
How Do You Mitigate XXE When DTDs Can’t Be Disabled?
Sometimes you can’t follow the textbook. “Disable DTDs” is the ideal, but your company’s payment gateway runs on a SOAP API with a complex, DTD-dependent schema. Turning them off breaks production. When elimination isn’t an option, you switch to strict restriction.
If DTDs must stay enabled, you have to lock them down completely. Disable external entity resolution. Implement an EntityResolver that returns an empty input source, a “no-op” resolver. This lets the parser understand the internal structure while blocking any fetch for external resources.
// A no-op EntityResolver that stops all external resolution
EntityResolver noop = (publicId, systemId) -> new InputSource(new StringReader(""));
documentBuilder.setEntityResolver(noop);You also need to stop network calls. In .NET, set XmlResolver = null. Configure server-level network egress filtering so even a malicious payload can’t call out to an attacker’s server. This is defense in depth, creating a controlled, safe parsing environment instead of a full shutdown.
XXE Mitigation Options for Legacy Systems
| Approach | Security Level | Legacy Compatibility |
| Disable DTDs Completely | Highest | Low |
| Allow DTDs + No-Op Resolver | High | High |
| Default Parser Configuration | Low | High |
How Can You Verify Your XXE Fix Actually Works?
You changed the code. You think it’s secure. How do you know? You test it. This isn’t just about unit tests. You need to simulate an attack. The method is straightforward.
Use tools for testing for XXE vulnerabilities, like Burp Suite or OWASP ZAP. Intercept a normal request to your endpoint. Change the Content-Type header to application/xml. Insert a simple XXE test payload that tries to read a local file like /etc/passwd or trigger a call to a web server you control.
<?xml version="1.0"?>
<!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<test>&xxe;</test>Send the request. If your fix is correct, the response should not contain the contents of the passwd file. The parser should block common XXE attack examples. For SSRF testing, you’d point the entity to a URL on a server you monitor (http://your-monitor.com). If you get a hit, your parser is still making network calls. This hands-on validation is non-negotiable. It turns a theoretical fix into a verified control.
How Do You Build Long-Term Protection Against XXE?
Beating XXE long-term isn’t about a single config tweak. It’s a habit you build into your secure coding practices. Start by using explicitly hardened parsers, every single time.
The work continues with tools. A SAST scan in your CI/CD pipeline should flag insecure parser instantiations. Dependency scanning is non-negotiable, because a vulnerable XML library buried in a component that processes SVG icons can be your undoing.
We’ve seen the final layer fail: network hygiene. Apply the principle of least privilege to your servers. Why does the microservice handling file uploads need outbound internet access? Restricting egress traffic at the firewall is a last line of defense that can stop data exfiltration cold, even if a parsing flaw slips through. This layered mix of secure code, automated checks, and runtime restrictions is what truly manages the risk.
Research from IEEE shows
“Completely disabling external entities within XML parsers is the most effective approach for preventing XXE attacks. In addition, the research highlights the critical role of proper configuration and adherence to stringent security practices in XML parsing” – IEEE
FAQs
How can I strengthen XXE prevention in legacy XML applications?
You can strengthen XXE prevention by disabling external entities, prohibiting DTD parsing, updating XML parsers, patching XML libraries, and enforcing secure XML parsing settings.
Which XML parser settings best prevent XXE attacks?
The most effective settings disable doctype declarations, disable external DTD access, deny network entity resolution, restrict file access, and enable secure processing.
Is XML schema validation enough for XML entity attack defense?
XML schema validation improves input quality, but it cannot stop XXE alone. You must also sanitize XML input and disable external entities.
What coding practices support long-term XXE vulnerability mitigation?
Long-term XXE vulnerability mitigation requires secure coding XXE practices, removal of unsafe XML features, dependency scanning, least-privilege access controls, and reviews.
Should developers use JSON instead of XML for new projects?
Developers should use JSON instead of XML when possible because it reduces parser-related risks. If XML is required, implement XML external entity mitigation.
Secure Your XML Before It Becomes a Problem
XML vulnerabilities often stay hidden until they cause real damage. That’s the risk. By disabling unnecessary features, tightening parser settings, and reviewing every XML entry point, you can reduce XXE exposure before it turns into an incident.
If you want practical, hands-on training that helps developers build secure habits from day one, check out the Secure Coding Practices Bootcamp.
References
- https://blackhat.com/docs/webcast/11192015-exploiting-xml-entity-vulnerabilities-in-file-parsing-functionality.pdf#1#1
- https://ieeexplore.ieee.org/document/10779957