DTD Processing

What DTD Processing Does in XML Parsing

DTD processing is the parser stage that reads document type declarations, resolves entity rules, and applies the document type grammar before the XML payload is fully interpreted. That makes it part of XML parsing behaviour, not a separate feature, and it matters because parser defaults can change whether untrusted XML is merely parsed or also allowed to expand entities and fetch external references.

In practice, DTD support exists to make XML more expressive, but modern applications often do not need it. When enabled unnecessarily, it expands the parser’s attack surface without adding business value. The core question for defenders is whether the application truly depends on DTD features or whether they can be disabled to reduce risk.

Why DTD Processing Becomes Dangerous

The risk comes from the way DTDs can instruct a parser to substitute entities, recurse through nested definitions, or resolve external references. Those behaviours are useful for legitimate document handling, but they also create opportunities for entity expansion abuse and external entity attacks when the XML source is not trusted.

Attackers look for parsers that still honour DTD declarations because the parser may do work on their behalf before the application ever sees the final content. That can turn a seemingly harmless XML document into a mechanism for reading local files, probing internal network resources, or consuming parser resources through expansion loops.

XXE Guide

How Organisations Reduce Exposure

Exposure checks start with inventorying where XML is accepted, which parsers are used, and whether DTD support is enabled by default in those code paths. The relevant review is not just “does the application parse XML?” but “does any parser instance accept untrusted input with DTD and entity processing turned on?”

Teams should also look for internet-facing upload, API, integration, or document-processing features that accept XML from external parties. Vendor documentation and secure configuration guidance matter here because parser behaviour varies across languages and libraries, and safe defaults are not consistent.

When DTD support is unnecessary, the safest pattern is to disable DTD processing or external entity resolution in the parser configuration. Where XML handling must remain available, treat the parser as a security boundary and verify that the implementation matches the intended trust model.

What To Check After Parsing or Exploitation Attempts

Detection is often indirect because DTD abuse happens before the application logic runs. Watch for parser errors, unusual outbound requests triggered by XML ingestion, unexpected spikes in CPU or memory use, and logs that suggest entity expansion or external resource resolution during XML handling.

After a suspected exploit attempt, review whether the parser may have exposed local files, internal URLs, or sensitive application data. If the XML input reached a system that processes credentials, configuration files, or service metadata, treat the event as more than a parsing failure and assess possible follow-on exposure.

Post-incident review should include the specific parser settings in use at the time, because the same XML payload may be harmless in one configuration and exploitable in another. That makes configuration evidence as important as payload evidence.

Security Implications For Application Teams

DTD processing is a reminder that parser convenience can become security debt. If an application does not explicitly need DTD features, keeping them enabled is usually a poor trade-off because the parser is then allowed to interpret a richer document grammar than the business case requires.

For developers and reviewers, the practical standard is simple: treat untrusted XML as hostile input, prefer minimal parser features, and document any intentional reliance on DTD behaviour. A parser that accepts less is often safer than one that accepts everything by default.

secure XML parser settings are the right control point when deciding whether DTD functionality should exist at all.

Related resources from NHI Mgmt Group

• What breaks when SAML signature verification and assertion processing are separated?
• How can organisations reduce risk from AI agents processing hidden instructions?
• How should security teams enforce segregation of duties in payroll processing?
• How do organisations reduce blast radius if protobuf processing is compromised?