Document Type Definition (DTD) is a set of rules that defines the structure of an XML document, including permitted elements and attributes. Parsers can use it to validate documents, but external entities and overly permissive processing can introduce XML injection and data exposure risks. Defenders should disable features they do not need and validate inputs carefully.
What DTD actually does in XML processing
DTD is the schema-like layer that tells an XML parser what a valid document should look like. It can declare element names, attribute names, ordering, cardinality, and entities, so the parser can compare incoming XML against a defined document shape before the application consumes it.
That validation role is useful when you need consistency across XML producers, but it is also why DTD changes parser behaviour. If the parser is allowed to resolve external entities or process untrusted declarations, the document can carry instructions that reach beyond simple structure checking and into file access, network retrieval, or entity expansion.
For readers who want the wider attack surface around XML features, the Web Application Attacks Guide covers XXE, XML entity expansion, DTD injection, and related XML abuse patterns in one place.
Why DTD becomes a security issue
DTD is not inherently malicious, but it can become dangerous when applications accept XML from untrusted sources and the parser still honours external entities, parameter entities, or entity expansion. In those cases, the parser may be persuaded to disclose local files, make outbound requests, or consume excessive resources while resolving nested entities.
Another practical issue is overtrust. Teams sometimes treat “XML validation” as a security control in itself, but validation only helps when the parser configuration is tight and the application does not rely on unsafe features. A permissive DTD setup can validate structure and still leave room for injection, data exfiltration, or denial of service through expansion attacks.
Failure mechanism: The parser processes attacker-controlled DTD declarations, resolves external entities, or expands nested entities instead of treating the XML as inert input.
Impact: The application can leak sensitive data, make unexpected outbound requests, or become unstable under entity expansion or malformed XML processing.
How to use DTD safely, or avoid it entirely
In most modern applications, the safest decision is to disable DTD processing unless there is a clear business need for it. If the application must accept XML, configure the parser to reject external entity resolution and untrusted document type declarations, then enforce strict input validation before the XML reaches business logic.
If DTD is required for compatibility, keep the allowed document shape as narrow as possible and test the parser’s real behaviour, not just the intended configuration. A document can still pass basic validation while triggering entity expansion or other parser side effects if the runtime defaults are not locked down.
When XML comes from outside your trust boundary, treat DTD support as an attack surface, not a convenience feature. The safer pattern is to process only the structure you need and to remove features that can influence file access, network access, or parser recursion.
Risk and Threat Considerations
DTD-related risk usually appears where XML handling is exposed to users, partners, integrations, or upstream systems that are not fully trusted. The main threat is that parsing features meant for document structure can be repurposed to read data the application should not expose or to exhaust resources through repeated entity expansion.
Failure mechanism: An attacker supplies XML that leverages external entities, parameter entities, or recursive expansion so the parser follows attacker-influenced references or consumes abnormal CPU and memory.
Impact: The result can be sensitive file disclosure, SSRF-style outbound fetches, parser crashes, degraded service availability, or a broader foothold for further application abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | V4 — API and Web Service | XML parsing and validation in web services directly affects input handling and parser exposure. |
| V15 — Secure Coding and Architecture | Safe XML design requires removing risky parser capabilities and choosing safer data handling patterns. | |
| Recommendation — Harden XML handling in service inputs and reject unsafe parser features. Design out DTD dependence where possible and use safer parsing defaults. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | DTD abuse is an input-handling problem where untrusted XML must be validated before processing. |
| SC-18 — Mobile Code | External entity resolution lets untrusted document content influence execution-like retrieval behaviour. | |
| Recommendation — Validate XML inputs and constrain what the parser will accept. Disable untrusted external entity resolution and other remote retrieval features. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | XML parser hardening is an application security safeguard for unsafe document processing. |
| Recommendation — Harden application parsers and test them against XXE-style inputs. | ||
Practitioner Guidance
What to verify: Confirm the exact XML parser settings in the runtime you deploy, not just the library defaults in documentation. The important question is whether DTDs, external entity resolution, and expansion are actually disabled in production paths.
Decision rule: If the application does not need DTD for a known compatibility reason, disable it. If it must remain enabled, limit the parser to trusted sources, add regression tests for XXE-style payloads, and review whether the XML function can be replaced with a safer format or a stricter schema approach.
Practitioner takeaway: DTD is best treated as a parsing capability with security consequences, not as a harmless validation feature, so safe XML handling depends on reducing parser features as much as on validating document shape.