What is an XXE attack and how do you mitigate it?

XML External Entity (XXE) injection exploits a powerful and rarely-needed feature of XML: a document can define entities in its Document Type Definition (DTD), and those entities can point at external resources. When a misconfigured parser processes attacker-supplied XML, it happily resolves those external references — fetching whatever the attacker named.

What an attacker can do

The classic payload declares an entity that points at a local file:

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<foo>&xxe;</foo>

When the parser expands &xxe;, the file contents get pulled into the response — arbitrary file disclosure. The same trick with http:// makes the server fetch an internal URL, turning XXE into SSRF (including the cloud metadata endpoint). Even blind XXE, where the response is not echoed, can exfiltrate data out-of-band by having the entity trigger an outbound request to an attacker server. And recursive entity expansion (the "billion laughs" attack) can exhaust memory for a DoS.

Why it is so common

XML parsers in many languages historically enabled DTD and external-entity processing by default. Any endpoint that accepts XML — SOAP, SAML, SVG uploads, office documents, RSS — is a candidate, often where developers do not even realize XML is being parsed.

Mitigation

The reliable fix is to harden the parser:

• Disable DTD processing entirely where possible (e.g. disallow-doctype-decl).
• If DTDs are needed, disable external general and parameter entities.
• Keep parser libraries patched and prefer safe defaults.
• Where feasible, use a less dangerous format such as JSON.

Input validation alone does not help, because the danger is in parsing, not the data values.

Interviewers look for the external-entity mechanism, the trio of impacts (file read, SSRF, DoS), awareness of blind XXE, and "disable DTDs / external entities" as the fix rather than input filtering.