XXE Prevention: Hardening PHP and Node.js XML Parsers

During a routine audit of a legacy service last year, I found an endpoint that accepted user-provided XML to generate reports. It was a classic "set it and forget it" feature, but it was wide open to XML External Entity (XXE) attacks because the developer assumed the standard library would handle things safely by default. Spoiler: it didn't.

XXE prevention is one of those things you don't think about until you're staring at a /etc/passwd dump in your logs. If your application parses XML, you aren't just processing data; you're potentially giving an attacker a remote file reader or a blind SSRF vector.

The mechanics of the threat

An XXE attack exploits the ability of XML parsers to define custom entities. By injecting a DOCTYPE declaration, an attacker can force the parser to fetch local files or external URLs and include them in the document output.

If you aren't careful, your parser might resolve:

XML
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "file:///etc/hostname">
]>
style="color:#808080"><style="color:#4EC9B0">root>&xxe;style="color:#808080"></style="color:#4EC9B0">root>

If your application returns the parsed content back to the user, you've just handed over your server's metadata. Even if the application doesn't return the content directly, attackers use "blind" XXE to exfiltrate data via HTTP requests to their own servers.

XXE prevention in PHP

PHP's libxml library is powerful, but it’s historically been insecure by default. You have to explicitly flip the switches to harden your configuration. For years, I relied on libxml_disable_entity_loader(true), but as of PHP 8.0, that function is deprecated because the underlying library now disables external entities by default.

However, if you're stuck on an older version or want to be absolutely certain, here is the robust way to handle it:

PHP
#6A9955">// Explicitly disable external entity loading
libxml_use_internal_errors(true);
$dom = new DOMDocument();
#6A9955">// Disable loading of external entities
$dom->substituteEntities = false; 

#6A9955">// If you are using SimpleXML, convert to DOMDocument first
$xml = simplexml_import_dom($dom);

If you are using libxml_disable_entity_loader(true) in your codebase, keep it, but know that you need to be testing against modern PHP versions to ensure your environment defaults are actually secure. I’ve seen teams migrate to PHP 8.2 and assume their legacy hacks were still doing the heavy lifting, only to realize the library behavior had shifted under their feet.

XXE prevention in Node.js

In the Node.js ecosystem, we usually reach for libxmljs2 or xml2js. The security profile of these libraries varies wildly.

If you use libxmljs2 (a wrapper around libxml), you must explicitly tell it not to resolve entities. By default, it might be safer than standard PHP, but "might" isn't a security strategy.

JAVASCRIPT
const libxmljs = require("libxmljs2");

// Always parse with these options to prevent XXE
const xml = CE9178">'<root>...</root>';
const doc = libxmljs.parseXml(xml, { 
    dtdload: false, 
    noent: false, 
    nonet: true 
});

• dtdload: false: Prevents the parser from loading external DTDs.
• noent: false: Prevents entity substitution.
• nonet: true: Disables network access for the parser, which is your final line of defense against SSRF.

If you're using xml2js, it’s generally safer because it doesn't support DTDs out of the box, but you should always verify your versioning and avoid plugins that add "extra" XML processing capabilities. Just like handling Insecure Deserialization: How to Secure Object Hydration in Node.js and PHP, the key is knowing exactly what your parser is configured to allow.

Hardening your architecture

Beyond just configuration, look at how your application handles file paths and user input. If you're building a system that processes XML, ensure you aren't inadvertently opening doors for other vulnerabilities. For example, if your XML contains file paths, make sure you've implemented strict Preventing Path Traversal: Secure File System Access for Developers checks to prevent an attacker from escalating their access.

I’ve found that the best way to maintain secure parsing is to treat all XML input as untrusted, regardless of the source. Even if the request comes from an internal service, that service could be compromised.

FAQ

Q: Should I just stop using XML? A: If you can, yes. JSON is significantly easier to secure because it lacks the complex entity-resolution features that make XML dangerous. However, if you're dealing with SOAP or legacy enterprise APIs, you're stuck with XML.

Q: Does disabling DTDs break my application? A: It might, if your XML relies on complex DTDs for validation. If you absolutely need DTDs, ensure you are using a schema-based validation (like XSD) that doesn't rely on remote entity resolution.

Q: How do I know if I'm currently vulnerable? A: Run a local test with a payload containing an external entity pointing to a local file. If your code outputs the contents of that file, you have a vulnerability.

I’m still not 100% comfortable with how some third-party NPM packages handle XML under the hood. When in doubt, I prefer to write a small wrapper that forces a "safe" parser configuration, or I use a JSON-based proxy to strip out all DOCTYPE declarations before they ever touch my core business logic. It feels like extra work, but it beats an emergency patch session on a weekend.