DOCTYPE Injection is an attack where an attacker adds or controls a DOCTYPE declaration in XML. That can enable entity expansion, external entity loading or parser behaviour changes, which may expose files, trigger server requests or distort how the XML is processed.
What DOCTYPE Injection Does
DOCTYPE injection is dangerous because the DOCTYPE declaration sits near the start of XML parsing, where it can alter how the parser resolves entities before the document body is processed. That makes it a high-leverage entry point for changing parser behaviour and influencing downstream data access.
The core issue is not the DOCTYPE token by itself, but the parser features it can activate. If a parser allows external entities, parameter entities, or permissive document type handling, attacker-controlled markup can redirect reads, expand data unexpectedly, or trigger network access from the server side.
Why It Becomes a Security Problem
When DOCTYPE handling is left enabled in an unsafe configuration, the parser may interpret attacker input as instructions rather than plain structure. This can expose local files, amplify small inputs into large parser workloads, or create server-side requests that the application never intended to make.
That makes DOCTYPE injection especially dangerous in XML-consuming services that trust inbound documents from users, partners, integrations, or uploaded files. The risk grows when the application parses XML automatically and the parser defaults are not explicitly hardened.
Common Exposure Patterns
Exposure usually comes from unsafe XML parsing paths rather than from XML in general. Typical patterns include file upload handlers, API endpoints, import jobs, SSO or metadata processing, and internal services that accept XML from external systems.
- Parsers that allow external entity resolution.
- Services that process untrusted XML without a hardened parser profile.
- Endpoints that pass XML into downstream libraries or transformations.
Attackers often look for places where XML is accepted as a convenience format, then use DOCTYPE control to influence parser behaviour. The issue can remain invisible until the parser attempts to resolve an entity or dereference a resource.
Prevention, Detection, and Review
The safest approach is to disable DOCTYPE processing and external entity resolution wherever the application does not require them. If XML is genuinely needed, use a parser configuration that rejects unsafe constructs by default and apply tight input validation around the exact XML features in use.
Monitoring should focus on parser errors, unusual outbound requests, unexpected file reads, and transformations that suddenly behave differently after XML input is processed. After any suspected exploitation, review whether credentials, local files, configuration data, or internal endpoints may have been exposed through the parser path.
For broader context on XML and application-layer attack patterns, see the OWASP Top 10.
Risk and Threat Considerations
DOCTYPE injection can turn a parsing feature into an access path, which is why it is often treated as a high-impact XML weakness. The most serious outcomes are data disclosure, server-side request generation, and parser-driven denial of service when expansion rules or recursive entity handling are abused.
Failure mechanism: The parser accepts attacker-controlled DOCTYPE content and uses it to resolve entities or fetch referenced resources, allowing the input to change what the server reads or requests.
Impact: Sensitive files, internal services, or parser resources may be exposed or consumed, and the application may process attacker-supplied XML in a way that breaks confidentiality, availability, or integrity.
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 | DOCTYPE injection affects XML handling in web services and APIs. |
| V13 — Configuration | Unsafe XML parser defaults are a configuration weakness that enables DOCTYPE abuse. | |
| Recommendation — Harden XML processing in API and web service components against unsafe parser behaviour. Disable unsafe XML parser options and enforce secure defaults for document processing. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Rejecting unsafe XML constructs is a form of input validation against parser abuse. |
| SC-7 — Boundary Protection | Blocking parser-triggered external entity requests supports boundary protection. | |
| Recommendation — Validate XML input so malicious DOCTYPE content is rejected before parsing. Restrict outbound parser-initiated connections and isolate XML-processing boundaries. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure XML parsing is an application security safeguard for input handling. |
| Recommendation — Review XML processing code and libraries for unsafe entity handling and parser defaults. | ||