Document Type Definition (DTD)

What DTD Means in XML Security

A DTD is the part of XML that describes permitted elements, attributes, and entities. That makes it useful for validation, but also risky because entity resolution can turn a parser into an unexpected data-access or request-making component.

Security issues arise when parsers accept DTDs by default or allow external entities, parameter entities, or other unsafe declarations. In practice, the risk is less about the DTD syntax itself and more about how the XML parser interprets it.

How DTDs Are Abused

The classic abuse path is XXE, where hostile XML causes the parser to read local files, reach out to internal services, or disclose data through error messages or out-of-band requests. A DTD can be the mechanism that defines those entities and makes the parser process them.

That is why a secure parser configuration matters as much as application input validation. If the application accepts XML from untrusted sources, the parser must be configured to reject external entity expansion and other features that are not required for the business case.

For a broader view of parser abuse and attacker technique mapping, MITRE ATT&CK Enterprise Matrix is useful when you want to relate XML parser abuse to credential access, discovery, and lateral movement patterns.

Where Exposure Usually Comes From

DTD exposure is often created by legacy parser defaults, reused XML libraries, or code paths that process documents from partners, integrations, or uploaded files. The same application may be safe for one endpoint and vulnerable for another if parser settings differ between services.

Organisations should treat XML parser configuration as an inventory and governance problem, not just a coding issue. If XML is still in use, teams need to know where it is accepted, which parsers are in play, and whether any path still permits external entity processing.

For security baselines that cover parser hardening, configuration control, logging, and access restrictions, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the most relevant control catalogue.

Secure Handling and Detection

The safest pattern is to disable unnecessary DTD processing entirely and enable only the XML features the application truly needs. When DTD support is unavoidable, parser behaviour should be explicitly reviewed, because secure-by-default assumptions are not reliable across libraries and language runtimes.

Detection should focus on unusual outbound requests, parser errors that mention entity resolution, and unexpected file access patterns in services that consume XML. After a suspected exploit, review whether any data may have been disclosed through the parser and whether downstream systems saw follow-on abuse.

For organisations formalising zero-trust assumptions around parser access to data and internal resources, NIST SP 800-207 Zero Trust Architecture is a useful reference point for limiting implicit trust in internal components.

Risk and Threat Considerations

DTD risk is material because a single unsafe parser setting can expose files, metadata, internal endpoints, or cloud-local services through XML processing. The same weakness can also be used as a request-abuse primitive against internal systems that were never meant to be reachable from the application layer.

Failure mechanism: A parser expands attacker-controlled entities or follows external references, which can trigger local file disclosure, blind outbound requests, or server-side request abuse through XML processing.

Impact: The result can include data exposure, internal network reconnaissance, credential leakage from files or responses, and a foothold for wider compromise if the service trusts the XML source too much.

Practitioner Guidance

Why practitioners should care: DTD safety is usually a parser-setting issue, not just an input-filtering issue. Teams should verify XML library defaults, because a secure application can still inherit unsafe behaviour from a dependency or framework update.

What to watch for: Any endpoint that accepts XML from users, partners, or upstream services deserves a parser review, especially when the business process does not truly require DTDs or entity expansion. If DTD support is unnecessary, remove it rather than relying on downstream detection.

Related resources from NHI Mgmt Group

• What do teams get wrong when they rely on file type icons and folder names to judge whether a document is safe?
• Document Type Declaration Disabling
• When is SMS authentication not enough for document signing?
• How can teams prove who actually signed a document?