DTD Injection is the insertion of a malicious Document Type Definition into XML processing so the parser resolves attacker-controlled entities or changes document behaviour. Attackers use it for file disclosure, server-side request forgery or denial of service. Defenders should disallow DTD processing, validate XML sources and use hardened parsers.
What DTD Injection Does to XML Parsing
DTD injection exploits the parser’s ability to accept and resolve a supplied Document Type Definition, turning a normal XML document into one that can pull in attacker-controlled entities or alter how the document is interpreted. That makes the parser itself part of the attack surface, not just the application logic around it.
XML processors are vulnerable here because DTD handling can trigger external entity resolution, entity expansion, or document structure changes before the application ever sees the parsed data. When that behaviour is enabled in a parser that was not designed for hostile input, the parser may fetch remote resources, read local files, or spend excessive resources expanding crafted input.
Why DTD Injection Is Dangerous
The most serious consequence is that a parser may obey instructions embedded in the malicious DTD instead of treating the XML as passive data. That can create file disclosure, server-side request forgery, and denial of service, especially when the XML source is untrusted or when the application processes uploads, web service payloads, or integration traffic.
DTD injection is closely related to broader XML parser abuse patterns, including entity expansion and external entity exploitation. NHI Management Group’s Web Application Attacks Guide places DTD injection alongside XXE, SSRF, and other injection classes because they all rely on unsafe parser trust boundaries.
How Organisations Detect and Reduce Exposure
Exposure checks start with identifying every place XML is accepted, including APIs, SSO and federation flows, configuration importers, document upload features, and backend integrations. Teams should verify which parsers are in use, whether DTD processing is enabled, and whether the application can reach internal or external resources during XML parsing.
Hardening usually means disabling DTD processing where it is not required, restricting external entity resolution, and using secure parser defaults rather than custom parsing logic. Validation should also cover supplier libraries and frameworks, because a safe application can still inherit unsafe XML behaviour from a dependency.
For baseline web application risk context, the OWASP Top 10 remains a useful reference point for understanding how injection flaws and insecure input handling recur across modern applications.
Remediation, Detection, and Post-Incident Review
If DTD injection is suspected, defenders should review parser settings, outbound network access from the XML-processing service, and logs for unusual fetches or parsing failures. Detection is often indirect, because the malicious behaviour may occur inside the parser before the application records a clear error.
After remediation, organisations should reassess any secrets, files, or internal services that may have been exposed through entity resolution or SSRF. If the parser could reach sensitive internal endpoints, the compromise review should also look for follow-on access paths created by stolen data, trusted metadata endpoints, or internal-only resources.
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 OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | XML parsing safety depends on rejecting hostile input and unsafe parser behaviour. |
| V4 — API and Web Service | DTD injection often enters through XML APIs and service integrations. | |
| V15 — Secure Coding and Architecture | Secure XML handling is an architectural choice about parser defaults and trust boundaries. | |
| Recommendation — Apply V1 to validate XML input handling and block parser behaviours that process attacker-controlled markup. Apply V4 to harden XML-facing services against malicious payloads and unsafe entity resolution. Apply V15 to remove unsafe XML parsing patterns and enforce secure parser configuration. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | DTD injection is enabled by accepting and processing untrusted XML input unsafely. |
| SC-18 — Mobile Code | External entity retrieval can cause a parser to fetch and execute or interpret external content pathways. | |
| Recommendation — Use SI-10 to validate XML sources and reject hostile document structures before parsing. Use SC-18 to restrict any external content retrieval path exposed during XML processing. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | XML parser hardening and safe input handling are application security practices. |
| Recommendation — Use CIS-16 to secure XML parsing code and eliminate unsafe DTD processing. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Leaving DTD processing enabled is a common parser configuration weakness. |
| Recommendation — Apply API8 to remove unsafe XML parser settings and disable DTD processing where possible. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | DTD injection commonly targets exposed XML handlers to gain file disclosure or SSRF. |
| Recommendation — Map exposed XML handlers to T1190 and hunt for exploitation attempts in public-facing services. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org