How does Document Type Definition (DTD) work?

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.

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.

Related resources from NHI Mgmt Group

• Document Type Definition (DTD)
• How can fraud teams and IAM teams work together after a document loss?
• When do privacy-preserving age verification methods work better than document-heavy checks?
• How do document verification and biometric checks work together in fraud prevention?