DTD is targeted mainly through XML external entity attacks, entity expansion bombs, and injection into parsers that process untrusted XML. Weak parser settings can let attackers read local files, reach internal systems, or exhaust resources. Defenders should disable DTD processing where it is not needed, restrict external entity resolution, and sanitise XML inputs before parsing.
How DTDs Become an Attack Surface
A Document Type Definition becomes dangerous when a parser is allowed to resolve entities, load external references, or expand attacker-controlled content during XML parsing. The risk is not the DTD alone, but the parser behaviour around it. In practice, that means XML processing can cross trust boundaries, pull in local or remote resources, or turn a small input into a much larger workload.
DTD-related attacks usually exploit one of three behaviours: external entity resolution, recursive entity expansion, or unsafe parser handling of special markup. The parser may be reading XML for a routine business function, but once DTD processing is enabled, the input can influence what the parser fetches, how much memory it consumes, and what data becomes visible to the application.
For a broader map of these patterns, see Web Application Attacks Guide, which covers XXE, entity expansion, and related XML abuse patterns in context.
What the Main Attack Types Look Like
XML external entity attacks are the most common DTD abuse path. An attacker supplies XML that defines an external entity and tricks the parser into resolving it. If the parser permits that resolution, the entity may point to a local file, an internal URL, or another resource the application should never expose.
Entity expansion bombs work differently. Instead of reaching outward, they exploit recursive or repeated entity definitions so that a small request expands into an enormous in-memory structure. That can consume CPU, memory, or parser time, causing degradation or denial of service. The attack is effective because the parser does the amplification work before the application can reject the request.
DTD injection into parsers is another practical path when applications accept untrusted XML and do not lock down parser features. The attacker does not need a separate exploit if the parser is already configured to interpret DTDs, external entities, or parameter entities. In those cases, the XML document itself becomes the delivery vehicle for file disclosure, internal network access, or resource exhaustion.
Attackers often combine these behaviours with other XML weaknesses, such as insecure schema handling or improper input validation, because the parser boundary is where trust is decided. Once the parser accepts attacker-controlled structure as “normal” XML, the application may inherit the parser’s mistakes.
How to Reduce Exposure in Practice
The safest default is to disable DTD processing wherever the application does not truly need it. If a business case requires DTD support, restrict external entity resolution, disable unnecessary parser features, and test the exact parser library rather than assuming a framework default is safe. XML security is frequently lost in configuration, not code.
Sanitising XML inputs before parsing helps, but it is not a substitute for parser hardening. The parser must be treated as the enforcement point, because an attacker can hide dangerous instructions in otherwise well-formed XML. Validation should happen against a strict allowlist of expected structure and content, with special care for any application that accepts uploads, integrations, or partner-supplied XML.
Operationally, teams should also watch for parser exceptions, unusual outbound requests during XML handling, and resource spikes tied to XML endpoints. If the application processes XML from third parties, confirm whether the parser can reach internal hosts or local files, because that decides whether an XXE attempt becomes a data exposure event or merely a blocked request.
Risk and Threat Considerations
DTD abuse matters because the parser can become an unintended bridge between untrusted input and sensitive internal resources. A successful attack may expose configuration files, credentials, or internal service endpoints, or it may overload the application through expansion-based denial of service.
Failure mechanism: The application allows DTD processing, external entity resolution, or uncontrolled entity expansion in XML supplied by an attacker, and the parser performs the dangerous work before the application can intervene.
Impact: The result can be local file disclosure, internal network access, credential leakage, parser crash, or service degradation, depending on what the parser is permitted to resolve and how much resource amplification the input creates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | DTD risk often comes from unsafe parser settings that expose XML processing features. |
| Recommendation — Harden XML parser settings and disable dangerous defaults before processing untrusted XML. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | XML parser hardening and input handling are application security implementation concerns. |
| Recommendation — Secure XML handling by validating inputs and removing unnecessary parser capabilities. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted XML must be validated before parsing to prevent entity abuse and injection. |
| Recommendation — Validate XML inputs and reject malformed or dangerous content before parser processing. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Safe XML parsing depends on secure design choices, including disabling risky parser features. |
| Recommendation — Design XML processing to avoid DTDs and other parser behaviors that expand attack surface. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | DTD abuse commonly reaches apps through crafted XML sent to exposed services. |
| Recommendation — Hunt for crafted XML inputs and treat parser-triggered resource access as exploitation activity. | ||
Practitioner Guidance
What to verify: Confirm which XML parsers, libraries, and frameworks are in use, because safe defaults vary. Check whether DTDs are disabled, whether external entities are blocked, and whether the parser can make outbound requests or read local resources during XML processing.
Decision rule: If the XML source is untrusted or only partially trusted, treat DTD support as an exception and require explicit justification. If the application does not need DTDs, remove the capability rather than relying on downstream filtering or developer discipline.
What good looks like: XML parsing is bounded, deterministic, and unable to resolve attacker-controlled external references. The application can accept legitimate XML without exposing file systems, internal networks, or process stability to the parser layer.
Practitioner takeaway: The key control is not “filter harder”, it is to make the parser incapable of turning untrusted XML into file access, internal reachability, or resource amplification.