XML External Entity (XXE) Injection is a web security vulnerability in which an application processes attacker-controlled XML with a parser that is allowed to resolve external entities or other external XML resources. That unsafe parser behavior can expose local files, trigger server-side requests to internal or external systems, or create other unintended resource access.
The key security boundary is simple: the attacker controls the XML reference, but the parser performs the access using the application’s filesystem and network position. XML itself is not the vulnerability. The problem is unsafe external-resource processing in attacker-influenced XML.
Classification noteMITRE classifies XXE as CWE-611: Improper Restriction of XML External Entity Reference. In the OWASP Top 10:2025, CWE-611 is mapped under A02: Security Misconfiguration.
What Is XXE (XML External Entity Injection)?
XXE is an XML parser vulnerability that occurs when attacker-controlled XML can make the parser resolve external resources without sufficient restrictions. Those resources can include local files, external URLs, internal services, external DTDs, or other XML resources reachable by the application.
Classic XXE usually involves XML entities defined through a DTD. An external entity points outside the XML document, and a vulnerable parser may resolve that reference using the server’s own file and network access.
| Entity | Role in XXE |
|---|---|
| XML | The structured data format the application processes |
| XML parser | The component that interprets the XML document |
| DOCTYPE / DTD | Can define entities and document structure |
| XML entity | A named value or reference used inside XML |
| External entity | An entity whose value is loaded from a resource outside the document |
| External resource | A local file, URL, external DTD, or other resource the parser may try to resolve |
The presence of XML or a DOCTYPE declaration alone does not prove XXE. The vulnerability exists when attacker-influenced XML causes the parser to resolve external resources that the application should not access.
How Does an XXE Attack Work?
An XXE attack works when attacker-controlled XML reaches a parser that resolves an external reference, causing the application server to access a local or remote resource the attacker could not access directly.
- The application accepts or processes XML: The XML may arrive through an API request, SOAP message, file upload, document parser, integration, or another XML-processing path.
- The XML contains an external reference: The document defines or influences a reference to a local file, URL, external DTD, or another external resource.
- The XML parser processes that reference: If DTD or external-resource resolution is enabled, the parser attempts to resolve the resource.
- The server accesses the resource: The parser uses the application’s own filesystem permissions and network reach to perform the access.
- The result becomes observable: The resource may be returned in the application response, influence an error, trigger a server-side request, or create an out-of-band interaction.
Core XXE relationshipAttacker controls reference → XML parser resolves resource → server filesystem or network trust is used → data or side effects may become observable.
How Do XML Entities and DTDs Enable XXE?
DTDs enable XML entities to be declared, and external entities can reference resources outside the XML document. XXE occurs when attacker-controlled XML can influence those references and the XML parser is configured to resolve them.
The process works in this order:
- The XML document declares a DOCTYPE: The
DOCTYPEdeclaration tells the XML parser that the document uses a Document Type Definition (DTD), which can define entities and other XML rules. - The DTD defines an XML entity: An entity acts like a named value or reference. An internal entity stores its value inside the XML document, while an external entity can point to a resource outside the document.
- The external entity identifies an external resource: The entity can reference a resource through a URI or system identifier, such as a local file, external URL, or another resource reachable by the application.
- The XML document references the entity: When the parser encounters the entity reference in the XML content, it determines whether that entity should be expanded or resolved.
- The parser resolves the external reference: If external entity resolution is enabled, the parser may access the referenced resource using the application’s filesystem permissions or network position.
- The parser crosses the XML trust boundary: If attacker-controlled XML can cause the parser to access a resource that should not be reachable through the XML input, the unsafe behavior can become an XXE vulnerability.
The relationship can be summarized as DOCTYPE → DTD → entity declaration → external resource reference → parser resolution.
Why parser configuration mattersThe XML document supplies the reference, but the parser decides whether external resources are allowed to be resolved. This is why disabling unnecessary DTD processing and external entity resolution is central to XXE prevention.
XXE Vulnerability Example
A basic XXE example is an XML document that defines an external entity and references a resource outside the XML document. If the parser is configured to resolve that entity, it may read or request the external resource.
A simplified example looks like this:
<!DOCTYPE data [
<!ENTITY example SYSTEM "file:///path/to/resource">
]>The important behavior is not the exact path. The security issue is that the parser is willing to follow an attacker-controlled external reference. If the entity value is later inserted into application output, local content may be exposed. If the reference points to a network location, the parser may instead cause a server-side request.
What makes this XXE?The XML controls an external reference, the parser resolves it, and that resolution reaches a resource outside the intended XML document. A parser that rejects external resolution would not exhibit the same XXE behavior.
Where Can XXE Vulnerabilities Appear?
XXE can appear anywhere an application or library processes attacker-influenced XML, including places where the user may not realize XML is being used.
| Attack Surface | Why XML May Be Involved |
|---|---|
| XML APIs | The endpoint directly accepts XML request bodies |
| SOAP services | SOAP messages are XML-based |
| SVG uploads | SVG is an XML-based image format and may be parsed server-side |
| XML-based documents | Some office and document formats contain XML components that may be extracted and parsed |
| Backend integrations | Applications may exchange XML internally even when the public interface uses another format |
| Data transformation | Input may be converted into XML before downstream processing |
| Alternate content types | An endpoint may unexpectedly accept XML even when the normal client sends another format |
| XInclude or external XML resources | Separate XML inclusion mechanisms can create similar external-resource behavior |
Finding XXE therefore requires more than checking visible application/xml endpoints. XML processing may exist in upload pipelines, background jobs, integration layers, document conversion, or parser libraries that are not obvious from the user interface.
What Is the Risk of XXE?
The risk of XXE is unauthorized access to files or network resources through the application’s XML parser, which can lead to sensitive data exposure, SSRF, internal-service access, blind data leakage, and in some environments availability or chained compromise.
| XXE Risk | What Can Happen |
|---|---|
| Local file disclosure | The parser reads files available to the application process and the content becomes observable |
| Server-Side Request Forgery (SSRF) | The parser makes a network request from the server to an attacker-chosen destination |
| Internal-service access | The server reaches services or endpoints that are not directly exposed to the attacker |
| Sensitive information exposure | Configuration, files, or backend responses may become visible |
| Blind or out-of-band leakage | External DNS or HTTP interactions can reveal parser behavior even when the normal response contains no data |
| Availability impact | Related XML parser features can consume excessive resources if entity expansion or external retrieval is unrestricted |
| Chained compromise | XXE may contribute to a larger exploit chain depending on parser capabilities, reachable services, and environment permissions |
XXE does not automatically mean remote code execution. RCE requires additional vulnerable components, parser behaviors, or reachable services. The most direct XXE impacts are usually file/resource access and server-side requests.
Common XXE Attack Patterns
Common XXE attack patterns differ mainly in what external resource is resolved and whether the result is visible in the application’s normal response. These are practical patterns rather than a universal formal taxonomy.
Direct / In-Band XXE
Direct XXE occurs when the resolved external resource is returned or reflected in the application’s normal response. This is the easiest form to observe because the effect appears directly in application output.
XXE for Local File Disclosure
Local file disclosure occurs when an external entity points to a file resource and the parser is permitted to read it. The impact depends on the filesystem permissions of the application process and whether the resulting content becomes visible.
XXE Leading to SSRF
XXE can cause SSRF when the external entity points to a network URL and the parser sends the request from the server environment. The server’s network position may allow the request to reach internal services or destinations the attacker cannot contact directly.
Blind XXE
Blind XXE occurs when the parser resolves the external resource but the resulting value is not returned in the normal application response. The vulnerability still exists, but response-based confirmation is harder.
Out-of-Band XXE
Out-of-band XXE is a blind XXE pattern where an external DNS or HTTP interaction is used to confirm that the parser resolved an attacker-controlled external reference. This is especially useful when the application’s normal response contains no visible evidence.
Error-Based XXE
Error-based XXE occurs when parser errors reveal information about external resource resolution. The parser may expose resource content, paths, or other details in an error message when unsafe XML processing affects error handling.
What Is Blind XXE?
Blind XXE is an XXE vulnerability where the parser resolves an external resource but the resolved value is not returned in the application’s normal response.
The main difference is observability:
| Behavior | Direct XXE | Blind XXE |
|---|---|---|
| External resource resolved | Yes | Yes |
| Resource value returned normally | Often | No |
| Typical confirmation | Application response | DNS/HTTP callback, timing, logs, or parser error behavior |
Blind XXE matters because a parser can still make unauthorized external requests even when the application never reflects the fetched content. Out-of-band monitoring is often used in authorized testing to confirm that external resolution occurred.
XXE vs SSRF: What Is the Difference?
XXE is an XML-processing vulnerability; SSRF is a server-side request vulnerability. XXE can cause SSRF when an XML parser resolves an attacker-controlled network URL.
| Question | XXE | SSRF |
|---|---|---|
| Primary entry point | XML parser and external XML references | Server-side request or URL-fetching functionality |
| Attacker controls | An XML reference or external resource declaration | A request destination or destination-related input |
| Local file access | Can be possible depending on parser and permissions | Not the defining SSRF behavior |
| Network request | Possible outcome | Core behavior |
| Relationship | XXE can create SSRF behavior | SSRF does not require XML |
For the broader server-side request model, see ScanTitan’s guide to Server-Side Request Forgery (SSRF).
Is Billion Laughs an XXE Attack?
Not exactly. Billion Laughs is an XML entity-expansion denial-of-service attack, but it does not require an external entity, so it is related to XXE rather than being classic external-entity XXE.
Classic XXE abuses external resource resolution. Billion Laughs instead abuses recursive or excessive internal entity expansion to consume parser resources. The two issues share XML parser features and prevention controls, but they are technically different mechanisms.
This distinction matters for both classification and remediation. Disabling external entity resolution addresses classic XXE, while entity-expansion limits and secure parser settings also matter for XML resource-exhaustion attacks.
How to Find XXE Vulnerabilities
Find XXE by identifying XML-processing inputs and verifying whether the parser can resolve external resources that should be blocked. Testing should be performed only in an authorized environment using controlled resources.
- Identify XML-processing surfaces: Review XML APIs, SOAP services, file uploads, SVG processing, document conversion, integration services, and background jobs.
- Determine which parser or library processes the XML: Different libraries have different defaults and security controls.
- Review DTD and external-resource settings: Check whether DTD processing, external entities, external DTDs, XInclude, schemas, or stylesheets can access outside resources.
- Test direct resolution safely: Verify whether a controlled external reference is resolved and whether the result becomes visible.
- Check for blind external interactions: Use controlled DNS or HTTP endpoints to determine whether the parser makes external requests when no result is reflected.
- Inspect hidden XML paths: Test upload processors, alternate content types, XML transformations, and backend services that may introduce XML indirectly.
- Review source and configuration: SAST and manual configuration review can identify unsafe parser initialization even when runtime behavior is difficult to reach.
For API-focused discovery and coverage, ScanTitan’s guide on how to scan an API for vulnerabilities explains why authenticated context, methods, headers, schemas, and non-browser endpoints all matter.
How to Prevent XXE
Prevent XXE by disabling DTD processing and external entity resolution wherever the application does not require them, then restrict any remaining external XML resource access. Secure parser configuration is the primary fix; network controls and WAF rules are defense in depth.
1. Disable DTD Processing Where Possible
Disabling DTD processing removes the main mechanism used by classic XXE. If the application does not require DTD functionality, this is the safest default because external entity declarations cannot be introduced through the DTD path.
2. Disable External General and Parameter Entities
If DTD support cannot be removed, disable both external general entities and external parameter entities. Leaving either external entity mechanism enabled can preserve unsafe resource-resolution behavior.
3. Disable External DTD Loading
Prevent the parser from fetching DTDs from external locations unless the application has a specific, controlled requirement. External DTD retrieval creates another path from attacker-influenced XML to remote resources.
4. Disable XInclude Unless Required
XInclude is a separate XML inclusion mechanism that can create similar external-resource risks. Disable it when it is not needed rather than assuming external entity controls automatically protect every XML inclusion feature.
5. Restrict External XML Resource Access
Restrict external DTD, schema, stylesheet, and other XML resource access to the minimum required set. Parser-level allowlists or external-access restrictions can reduce exposure where some external processing must remain enabled.
6. Apply Safe Parser Defaults and Resource Limits
Use secure-processing modes and entity/resource limits to reduce abuse of parser features. These controls are especially important for related XML entity-expansion and resource-exhaustion attacks.
7. Keep XML Libraries and Frameworks Updated
Keep XML libraries current, but do not treat updates as a substitute for secure configuration. A supported parser can still be exposed if external resource resolution is intentionally or accidentally enabled.
8. Restrict Filesystem and Network Privileges
Limit what the application process can read and where it can connect. Least-privilege filesystem permissions, network segmentation, and outbound restrictions can reduce the impact if unsafe parser behavior survives application-level controls.
9. Test Every XML Processing Path
Apply the same XXE controls to APIs, uploads, background jobs, document processors, integrations, and hidden XML transformations. Fixing one visible XML endpoint does not protect another parser instance elsewhere in the application.
Does Switching From XML to JSON Prevent XXE?
Removing XML from a feature eliminates XXE from that specific parsing path, but switching to JSON does not fix other components that still process attacker-controlled XML.
JSON does not use XML’s DTD and external-entity model, so a JSON-only endpoint cannot have classic XXE in that parser path. However, applications may still process XML in uploads, integrations, SAML, SOAP, SVG, document conversion, or internal services.
Use JSON when it fits the application design, but treat it as attack-surface reduction rather than a universal XXE remediation.
How Do You Fix XXE in Java or Spring Boot?
Fix XXE in Java or Spring Boot by securing the specific XML parser or API the application uses; there is no single Spring Boot switch that safely configures every XML parser.
For Java XML processing, the secure approach is to disable DTDs where possible, disable external general and parameter entities, block external DTD loading, and restrict external schema or stylesheet access. Java’s JAXP APIs also provide external-access properties that can limit which external resources XML processors are allowed to load.
Spring Boot applications may use different XML stacks through MVC converters, JAXB, SOAP libraries, document processors, or third-party dependencies. Each parser or marshaller should be verified separately rather than assuming framework-level configuration protects every XML-processing path.
The important rule is: secure the parser that actually processes the XML.
How Do You Fix XXE in JavaScript or Node.js?
Fix XXE in JavaScript or Node.js by identifying the XML library that actually parses the data and configuring it so DTDs and external entities are disabled or unsupported.
There is no single universal server-side JavaScript XML parser setting because Node.js applications commonly rely on third-party XML libraries. Security behavior therefore depends on the chosen parser and its options.
If the application does not require DTDs or external entities, use a parser configuration that refuses them. Also review related features such as external schemas, XInclude, or native-library options that may re-enable external resource access.
Can Vulnerability Scanners Detect XXE?
Yes. Vulnerability scanners can detect many XXE vulnerabilities when XML-processing behavior is reachable and observable, but blind and hidden XML processing may require out-of-band detection, authenticated coverage, or configuration review.
| Detection Method | Best At | Main Limitation |
|---|---|---|
| DAST | Direct runtime XXE where parser behavior affects the response | May miss asynchronous or hidden XML processing |
| Authenticated DAST | Protected XML APIs, uploads, and administrative workflows | Coverage depends on reaching the relevant parser path |
| OAST / OOB testing | Blind XXE and external network resolution | Requires controlled callback infrastructure and correlation |
| API scanning | XML and SOAP endpoints, alternate content types, request schemas | Undocumented transformations may remain hidden |
| Upload testing | SVG and XML-containing documents processed server-side | Depends on the actual server-side processing pipeline |
| SAST / configuration review | Unsafe parser creation, external entity settings, XInclude, external access controls | May not prove that the vulnerable path is reachable at runtime |
How Strong Is the Evidence for an XXE Finding?
| Observed Behavior | Interpretation |
|---|---|
| Application accepts XML | Normal behavior; not evidence of XXE |
| DOCTYPE is accepted | Potentially interesting, but not enough to confirm unsafe external resolution |
| Controlled external resource is resolved | Strong evidence that external resolution is enabled |
| Unauthorized local or remote resource content is returned | Confirmed direct XXE impact |
| Controlled DNS or HTTP callback occurs | Strong evidence of blind external resource resolution |
For broader methodology, see ScanTitan’s API security testing guide and vulnerability scanning vs penetration testing comparison.
ScanTitan’s Website Vulnerability Scanner can test web applications and APIs for runtime security weaknesses, while hidden XML-processing paths and complex blind behavior may require additional configuration review or manual validation.
Frequently Asked Questions
What is an XXE attack?
An XXE attack is an attack against unsafe XML processing in which attacker-controlled XML causes a parser to resolve an external resource such as a local file or network URL.
What is an XXE vulnerability?
An XXE vulnerability is a parser-security flaw where attacker-influenced XML can trigger external entity or related external-resource resolution without sufficient restrictions.
What is XXE injection?
XXE injection refers to supplying XML that introduces or influences an external entity or external XML resource so that an insecure parser accesses a resource outside the intended XML document.
What is XXE in cybersecurity?
In cybersecurity, XXE is a web and application security vulnerability involving unsafe XML parser behavior. It can expose files, trigger server-side requests, or create blind external interactions.
What is XXE processing?
XXE processing generally refers to an XML parser processing and resolving entity declarations, especially external entities that reference resources outside the XML document. The security problem occurs when untrusted XML can control that resolution.
What can XXE expose?
XXE can expose local files, configuration data, backend responses, or internal services, depending on what the parser process can read or reach and whether the result is returned or observable.
Can XXE cause SSRF?
Yes. XXE can cause SSRF when an XML parser resolves an attacker-controlled network URL and sends the request from the server environment.
What is blind XXE?
Blind XXE is an XXE vulnerability where external resolution occurs but the fetched value is not returned in the normal response. DNS or HTTP callbacks, timing, logs, or error behavior may provide evidence.
How do you prevent XXE?
Prevent XXE by disabling DTDs and external entity resolution where they are not needed, blocking external DTD loading and XInclude, restricting external XML resource access, applying safe parser limits, and testing every XML-processing path.
Can a vulnerability scanner detect XXE?
Yes. DAST can detect many direct XXE vulnerabilities, while blind XXE may require out-of-band monitoring. Hidden XML-processing paths may also require authenticated coverage, API discovery, upload testing, SAST, or configuration review.
