Understanding and Preventing XML External Entity (XXE) Attacks

XXE attacks are implemented through XML parser to process DOCTYPE declarations containing external entities, such as reading /etc/passwd files; 2. Common consequences include local file leakage, SSRF and denial of service; 3. Most of the APIs, file parsers and legacy XML libraries that accept XML input; 4. The core of the prevention is to disable DTD and external entities, give priority to using JSON instead of XML, strictly verify the input and keep the library updated, and you can effectively defend against XXE attacks.

XML External Entity (XXE) attacks happen when an application processes XML input that contains references to external entities—often malicious ones—leading to data exposure, server-side request forgery (SSRF), or even remote code execution in rare cases. Understanding how XXE works and how to prevent it is essential for secure application development.

What Is an XXE Attack?

At its core, XXE exploits the way XML parsers handle DOCTYPE declarations. These declarations can define custom entities that reference local or remote resources. For example:

 <?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<user>&xxe;</user>

If the XML parser processes this input without safeguards, it may read and return the contents of /etc/passwd —exposing sensitive system files.

Common outcomes of XXE:

• Reading local files (eg, config files, passwords)
• Accessing internal services via SSRF (eg, http://127.0.0.1:8080/admin )
• Denial of service via "billion laughs" attacks (entity expansion bombs)

Where XXE Happens Most

• APIs accepting XML uploads (eg, SOAP, REST with XML payloads)
• File parsers (eg, DOCX, ODF, or SVG files that embed XML)
• Legacy systems using older XML libraries with unsafe defaults

How to Prevent XXE

The key is to disable external entity processing in your XML parser. Here's how:

✅ Disable DTDs Entirely (Best Practice)

Most applications don't need DOCTYPE declarations. Just turn them off:

• Java (SAX, DOM, etc.) :

   DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
  dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
  // Or disable DTD completely:
  dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);

• Python (lxml) :

   from lxml import etree
  parser = etree.XMLParser(resolve_entities=False, no_network=True)

• .NET (System.Xml) :

   XmlReaderSettings settings = new XmlReaderSettings();
  settings.DtdProcessing = DtdProcessing.Prohibit; // or Parse only if needed
  settings.XmlResolver = null;

  ✅ Use Simpler Data Formats (If Possible)

  If you don't need XML, switch to JSON—it's less prone to parsing pitfalls and doesn't support entities by design.

  ✅ Validate and Sanitize Input

  Even with safe parsing, treat XML input like any untrusted data:

  • Whitelist expected elements/attributes
  • Reject XML with DOCTYPE if not required
  • Monitor for suspicious payloads (eg, file:// , http://internal )

  ✅ Keep Libraries Updated

  Older versions of libraries like Apache Xerces, older PHP XML parsers, or outdated .NET frameworks had unsafe defaults. Always use current, patched versions.

  Bottom Line

  XXE is a classic vulnerability that's easy to prevent—if you know to look for it. The biggest mistake? Assuming your XML parser is safe by default. It often isn't.
  Disable DTDs, avoid unnecessary XML complexity, and test your apps with known XXE payloads during security reviews.

  That's it—no magic, just solid defaults and awareness.

  The above is the detailed content of Understanding and Preventing XML External Entity (XXE) Attacks. For more information, please follow other related articles on the PHP Chinese website!