Reduce the risk by disallowing untrusted DTD content, disabling external entities, and using parsers configured to reject DTDs where they are not needed. Validate and sanitise XML before processing, and isolate XML handling from network and file access. Watch for input that tries to define entities, pull remote references, or expand parser work.
What DTD injection changes in XML processing
dtd injection is dangerous because the parser may be persuaded to process attacker-controlled document type declarations instead of ordinary element content. That shifts risk from simple data parsing to entity expansion, local file reads, remote retrievals, and parser behaviour that was never intended for untrusted input. The practical question is not whether XML is valid, but whether the parser will honour features that expand trust boundaries.
In most environments, the safest default is to treat DTD handling as an unnecessary feature unless you explicitly need it. If DTDs are enabled for a legitimate use case, the parser configuration, schema rules, and input source controls all need to be aligned, otherwise a single malformed document can trigger outbound requests or unexpected access to local resources.
Which parser settings and input controls matter most?
The most effective mitigations are to reject DTDs where they are not needed, disable external entities, and process XML with a parser configuration that refuses unsafe document type declarations by default. That reduces the attack surface before any validation logic runs. Validation and sanitisation still matter, but they should be treated as a later safety layer, not the primary defence.
XML handling should also be isolated from network and file access so that a parser cannot follow remote references or read sensitive paths even if an input slips through. For application teams, this usually means using hardened parser presets, avoiding ad hoc parser construction, and confirming that libraries in different languages do not re-enable entity resolution through convenience flags or legacy defaults.
A useful starting point is the broader attack family covered in the Web Application Attacks Guide, which includes XML external entity and related parser abuse patterns alongside DTD injection.
What should you do if DTDs are only sometimes required?
When DTD support is needed for a narrow workflow, the best pattern is to scope it tightly rather than leaving it enabled globally. Separate trusted XML pipelines from untrusted ones, and make sure any component that must accept DTDs is restricted to known sources, controlled schemas, and no outbound fetch behaviour. This is especially important where XML enters through APIs, file uploads, integration feeds, or middleware that may be assumed safe by downstream teams.
It is also worth checking whether your XML parser, transformer, or validation library has more than one place where entity expansion can be turned on. Teams often harden the main parser and miss a secondary code path, such as a validator, XSLT engine, or compatibility mode, that reintroduces the same exposure. If you cannot enforce a safe parser profile consistently, the better decision is to remove DTD reliance rather than accept partial mitigation.
For implementation details and attack-pattern context, OWASP Top 10 remains a useful reference point for injection-style failure modes in web applications, including XML-related abuse cases.
Risk and Threat Considerations
DTD injection becomes materially risky when a parser can reach outside the intended XML document boundary. The main hazards are entity expansion that drives resource exhaustion, external entity resolution that leaks files or causes server-side requests, and parser behaviour that turns a data-handling feature into a network or filesystem access path.
Failure mechanism: An attacker supplies XML that defines or references entities in a way that the parser honours, causing expansion, outbound retrieval, or disclosure of local content before the application has a chance to validate the payload.
Impact: Depending on parser behaviour and surrounding privileges, the result can range from denial of service to sensitive data exposure and unintended access to internal or local 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 addresses the attack and risk surface, while OWASP ASVS sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | DTD injection rides unsafe XML parsing and input handling. |
| V4 — API and Web Service | XML inputs often enter through APIs and service integrations. | |
| V12 — Secure Communication | External entities can trigger unwanted outbound network fetches. | |
| Recommendation — Harden XML parsing and sanitisation to reject unsafe document constructs. Validate XML-bound API inputs and block DTD processing at service boundaries. Prevent XML processors from making unauthorised outbound requests. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | DTD handling failures often stem from unsafe parser configuration. |
| API7 — Server Side Request Forgery | External entity resolution can coerce server-side requests. | |
| Recommendation — Disable risky XML parser features and enforce safe defaults. Block XML features that can be used to trigger server-side request forgery. | ||
Practitioner Guidance
What to verify: Confirm that every XML entry point uses the same hardened parser settings, and test specifically for DTD acceptance, entity resolution, and outbound reference handling. The common mistake is assuming one library default applies everywhere when a related component quietly behaves differently.
Decision rule: If the business process does not require DTDs, disable them and treat any exception as a design smell rather than a tuning choice. If DTDs are required, restrict them to trusted sources and verify that network and file access are blocked at the parser boundary, not only at the application layer.
Practitioner takeaway: DTD injection is best handled by removing parser features you do not need, because once entity processing is enabled, the blast radius depends on how much trust the parser is allowed to extend beyond the document.