XML External Entity (XXE) is a web application security vulnerability that occurs when an application processes untrusted XML using an insecurely configured parser. The vulnerability can allow an attacker to make the parser access resources outside the intended XML document, potentially exposing local files, making network requests, or causing denial-of-service conditions.
XXE is less common in modern applications than it once was, largely because many frameworks and parsers have improved their default security settings. However, XML is still widely used in enterprise systems, APIs, document-processing workflows, identity systems, configuration files, and older integrations.
That makes XXE worth understanding for both developers and penetration testers. A vulnerable XML parser can turn an apparently simple data-processing feature into a path toward sensitive files or internal services. OWASP recommends disabling external entity processing and DTDs whenever the application does not require them.
What Is XML External Entity (XXE)?
XML External Entity (XXE) is an injection vulnerability involving XML entities and external resource references.
XML supports a feature called a Document Type Definition (DTD). DTDs can define entities, which are reusable pieces of data that the XML parser replaces when processing the document.
An external entity can point to a resource outside the XML document.
Conceptually:
<!DOCTYPE example [
<!ENTITY data SYSTEM "external-resource">
]>When the parser processes a reference such as &data;, it may attempt to retrieve the referenced resource.
That behavior is useful in some XML applications, but it becomes dangerous when an attacker can control the XML and the parser is configured to resolve external entities.
MITRE classifies this weakness as CWE-611: Improper Restriction of XML External Entity Reference. The weakness can result in information disclosure, unauthorized outbound requests, or resource consumption.
Why Are XXE Attacks Important?
The main security issue is that an XML parser can have access to resources that the attacker cannot access directly.
For example, a public web application may not expose its server filesystem to users. But the application process itself may be able to read files from that filesystem.
If the XML parser is allowed to resolve external entities, attacker-controlled XML may influence what the parser attempts to access.
This can create several security consequences:
- Local file disclosure
- Server-side network requests
- Internal network discovery
- SSRF-like behavior
- Denial of service
- Exposure of application configuration
- Access to sensitive resources
- Potential chaining with other vulnerabilities
OWASP identifies file disclosure, SSRF, port scanning, and denial-of-service as possible consequences of XXE.
The actual impact depends on the parser, application architecture, operating-system permissions, network access, and how the XML response is handled.
How Does an XXE Attack Work?
Understanding the attack flow makes XXE much easier to recognize during application testing.
1. The Application Accepts XML
The application must first process XML supplied directly or indirectly by a user.
Common examples include:
- SOAP requests
- XML APIs
- SVG uploads
- SAML-related processing
- Document converters
- RSS or Atom feeds
- Configuration importers
- Enterprise integrations
- XML-based file formats
For example, an application may receive:
<?xml version="1.0" encoding="UTF-8"?>
<stockCheck>
<productId>381</productId>
</stockCheck>The backend passes this document to an XML parser.
2. The Parser Processes the Document
Normally, the parser converts XML into a structure the application can use.
The security problem appears when the parser also processes attacker-controlled DTD declarations and external entities.
3. The Attacker Defines an External Entity
In a vulnerable configuration, an attacker may introduce an external entity that references a resource.
For authorized security testing, the important concept is:
Attacker-controlled XML
↓
DOCTYPE / Entity Definition
↓
XML Parser
↓
External Resource
↓
Application Response or Side EffectPortSwigger’s Web Security Academy demonstrates how external entities can reference files or network resources when the XML parser permits this behavior.
4. The Application Processes the Entity
If the parser resolves the entity, the referenced content may become part of the parsed XML.
If the application subsequently returns that value, the attacker may be able to observe information that should never have been exposed.
Types of XXE Attacks
XXE is not limited to one exploitation technique. The outcome depends on how the application processes XML and how much information is returned.
In-Band XXE
In-band XXE occurs when the attacker can see the result of the external entity processing in the application’s response.
For example:
Malicious XML
↓
XML Parser
↓
External Resource
↓
Parsed Content
↓
HTTP ResponseThis is usually easier to identify because the application provides direct feedback.
Out-of-Band XXE
In an out-of-band or blind XXE scenario, the application does not directly return the retrieved resource.
Instead, the attacker may detect the behavior through a controlled external system during an authorized penetration test.
The important point is that lack of visible response does not automatically mean that the parser is secure.
A parser may still be resolving external resources even when their contents are not reflected in the application response.
XXE-Based SSRF
XXE can sometimes cause the vulnerable server to make requests to external or internal network resources.
This overlaps with Server-Side Request Forgery.
OWASP’s XML Security guidance specifically describes XXE-related SSRF scenarios where malicious XML causes the server to retrieve remote resources.
This is one reason XXE can become more serious in cloud and microservice environments.
XXE and Local File Disclosure
One of the most well-known XXE consequences is local file disclosure.
The basic security problem is that an XML entity can reference a local resource when the parser allows external entities.
For example, a vulnerable parser might process an entity referring to a local file.
The exact files that could be accessed depend on:
- Operating system
- Process permissions
- Container configuration
- Application sandboxing
- Parser behavior
- File permissions
MITRE documents local file access as one potential consequence of CWE-611.
For penetration testers, the key finding is not simply that a particular file can be read. The larger issue is that untrusted XML controls resource resolution inside the application environment.
XXE and Server-Side Request Forgery
XXE and SSRF are closely related but are not the same vulnerability.
SSRF generally involves an application making an unintended server-side network request.
XXE can become an SSRF mechanism when an XML parser resolves an external entity that points to a network resource.
The chain may look like:
Attacker
↓
Malicious XML
↓
XML Parser
↓
External Entity
↓
Internal Network ResourceMITRE notes that CWE-611 and CWE-918 are closely related because both can involve unexpected outbound requests, although XXE can also occur in contexts that do not involve a server acting as a network client.
This distinction matters when documenting penetration-testing findings.
XXE and Denial of Service
XXE can also affect application availability.
XML parsers have historically supported entity expansion and nested entity processing. Poorly controlled entity expansion can cause excessive resource consumption.
Potential consequences include:
- High CPU usage
- Excessive memory consumption
- Slow XML parsing
- Application crashes
- Service degradation
MITRE lists CPU and memory resource consumption among the potential consequences of CWE-611.
Modern XML libraries often provide protections against some entity-expansion problems, but developers should still configure parsers defensively and impose reasonable input limits.
Common XXE Attack Surfaces
SOAP APIs
SOAP commonly uses XML for request and response messages.
Legacy enterprise SOAP services deserve particular attention because they may use XML parsers with configuration that was designed before modern application-security practices became standard.
During a security assessment, testers should determine how the service parses incoming XML and whether DTD processing is enabled.
SVG File Uploads
SVG is an XML-based image format.
A file-upload feature that accepts SVG may therefore introduce an XML parsing attack surface.
Applications should not assume that an uploaded file is safe simply because it has an image extension.
The entire processing pipeline matters.
XML-Based Document Processing
Applications may process XML internally while converting:
- Office documents
- Reports
- Invoices
- Data feeds
- Configuration files
- Structured documents
A security review should consider every component that parses XML, including third-party libraries and conversion services.
SAML and Identity Systems
SAML uses XML extensively.
Modern SAML libraries normally include security controls, but identity-processing components should still be kept updated and configured according to vendor security guidance.
The safest approach is to use established libraries rather than implementing XML security logic from scratch.
Real-World XXE Vulnerability Examples
XXE is not merely a theoretical issue.
MITRE’s CWE-611 page lists observed vulnerabilities involving recruiter software, SVG conversion, PHP applications, database software, XML-RPC, and web administration tools.
These examples show why XML processing should be included in application security reviews even when the primary application is not obviously XML-focused.
A vulnerability may exist in a secondary component such as an image converter, document parser, integration service, or administration interface.
How to Test for XXE
XXE testing should only be performed against systems where you have explicit authorization.
A professional testing process starts with identifying XML-processing functionality rather than blindly sending payloads.
Step 1: Identify XML Endpoints
Look for:
Content-Type: application/xml
Content-Type: text/xml
SOAP requests
XML file uploads
XML API endpointsAlso inspect API documentation and application functionality.
Step 2: Understand the XML Parser
Determine which library or framework processes the XML when that information is available.
Different parsers have different configuration options and security defaults.
Step 3: Test External Entity Processing Safely
Use a controlled test environment or an external endpoint owned by the assessment team.
The goal is to determine whether the parser attempts to resolve an external entity.
Avoid accessing sensitive third-party systems during testing.
Step 4: Determine Whether the Result Is Reflected
Check whether the application’s response contains evidence of external entity resolution.
If no data is returned, consider whether the application may still be making an outbound request.
Step 5: Assess the Impact
Document whether the vulnerability could result in:
- Local file disclosure
- Network requests
- Internal service access
- Sensitive information exposure
- Denial of service
Do not access more data than necessary to demonstrate the security impact.
Tools for XXE Testing
Security professionals commonly use:
- Burp Suite
- OWASP ZAP
- Browser Developer Tools
- XML-aware testing tools
- Static analysis tools
- Controlled HTTP/DNS interaction servers
- SAST and DAST platforms
Burp Suite is particularly useful when testing XML APIs because it allows testers to inspect and modify HTTP requests while preserving the surrounding application workflow.
PortSwigger’s Web Security Academy also provides dedicated XXE learning material and controlled labs for practicing the vulnerability safely.
For practical security learning, <a href=”https://vuln.pentesthint.com/“>cyber security labs</a> can help you practice XML security concepts in controlled environments.
XXE Prevention Methods
The most effective XXE defense is to disable unnecessary XML features that allow external resource resolution.
Disable External Entities
If an application does not require external entities, disable them.
OWASP identifies disabling DTDs and external entities as the safest general approach.
The exact configuration depends on the XML parser and programming language.
Developers should follow the security guidance for the specific parser they use instead of copying configuration from an unrelated library.
Disable DTD Processing When Possible
DTD processing is often unnecessary for modern XML APIs.
If the application’s XML format does not require DTDs, disabling them removes an entire class of attack paths.
This is generally preferable to attempting to filter individual malicious entity declarations.
Use Secure Parser Configuration
Every XML parser should be reviewed for security-sensitive options.
Depending on the parser, these may include:
- External entity resolution
- DTD processing
- External DTD loading
- XInclude processing
- Network access
- Entity expansion limits
OWASP maintains language-specific recommendations because XML security configuration differs between parser implementations.
Validate XML Against an Expected Structure
Input validation can reduce unexpected XML structures.
For example, if an endpoint expects:
<order>
<id>123</id>
</order>the application should reject unexpected elements and structures where practical.
However, validation alone is not a replacement for disabling dangerous parser features.
Limit XML Input Size
Applications should impose sensible limits on:
- Request size
- XML nesting depth
- Entity expansion
- Processing time
- Memory consumption
This provides additional protection against resource-exhaustion attacks.
Restrict Outbound Network Access
If the XML parser or application does not need to make outbound network requests, restrict that capability.
Network-level controls provide useful defense in depth if an application-level mistake occurs.
This is particularly important for systems running in cloud environments or inside large internal networks.
Keep XML Libraries Updated
Third-party parsers and frameworks may receive security fixes over time.
Security teams should maintain an inventory of XML-processing dependencies and update them according to their organization’s patch-management process.
A secure parser configuration does not eliminate the need for dependency management.
Common XXE Prevention Mistakes
Blocking Specific File Paths
Blocking a handful of sensitive file paths is not a real XXE defense.
The underlying issue is external entity processing.
Disable the dangerous feature instead of maintaining a growing list of files to block.
Filtering DOCTYPE With a Regular Expression
Regular-expression filtering is fragile.
XML syntax is complex, and parsing behavior belongs in the parser rather than in ad-hoc filtering logic.
If DTDs are unnecessary, disable DTD processing at the parser level.
Assuming XML Is Safe Because It Is Structured
XML being structured does not make it trusted.
XML is a data format, but it also contains features that can influence how a parser retrieves and expands data.
The parser configuration is therefore part of the application’s security boundary.
Securing Only the Main Application
A web application may be secure while a document-conversion service, image processor, or background worker remains vulnerable.
Security teams should map the entire XML-processing pipeline.
XXE in Modern Cloud and Microservice Environments
Modern architectures introduce additional considerations.
A vulnerable XML parser running inside a cloud workload may have access to internal services that are not publicly exposed.
This means an XXE vulnerability can potentially become part of a larger attack chain.
For example:
Internet
↓
Public API
↓
XML Parser
↓
Internal Network
↓
Private ServiceThe application should therefore follow the principle of least privilege.
A service that only needs to process XML should not automatically have unrestricted network access to every internal system.
Network segmentation, egress filtering, workload identity, and strong service authentication can reduce the impact of an XML parser vulnerability.
XXE Security Checklist
Before deploying an XML-processing application, verify:
- DTD processing is disabled when unnecessary.
- External entity resolution is disabled.
- External DTD loading is disabled when unnecessary.
- XInclude is disabled unless explicitly required.
- XML input size is limited.
- Entity expansion is restricted.
- Outbound network access is restricted.
- XML libraries are regularly updated.
- XML upload functionality is included in security testing.
- SVG processing is reviewed separately.
- SOAP and XML APIs are tested.
- Background XML-processing services are included in the threat model.
- Security logging covers unexpected parser failures and suspicious XML input.
For teams looking to strengthen their application-security knowledge, <a href=”https://academy.pentesthint.com/“>cyber security training</a> can provide a practical foundation for understanding vulnerabilities such as XXE, SSRF, and injection attacks.
Frequently Asked Questions
What is XML External Entity (XXE)?
XML External Entity (XXE) is a vulnerability caused by insecure XML parser configuration. When untrusted XML can define and resolve external entities, an attacker may potentially make the parser access local files or network resources. MITRE classifies XXE as CWE-611.
What can an XXE attack do?
Depending on the parser and application environment, XXE can potentially cause local file disclosure, server-side requests, internal network access, denial of service, or other security impacts.
Is XXE still relevant today?
Yes. Although secure defaults have reduced the prevalence of some XXE vulnerabilities, XML remains common in enterprise applications, APIs, document processing, identity systems, and legacy integrations. XML-processing components should still be reviewed during security assessments.
How can developers prevent XXE?
The primary defense is to disable DTDs and external entity processing when the application does not require them. Developers should also use secure parser configurations, limit XML processing resources, restrict outbound network access, and keep XML libraries updated.
What is the difference between XXE and SSRF?
XXE is specifically related to unsafe XML external entity processing. SSRF is a broader vulnerability involving unintended server-side network requests. XXE can sometimes be used as a mechanism to trigger SSRF-like requests.
Can XXE affect APIs?
Yes. SOAP services and XML-based APIs are common XXE attack surfaces. Any API that parses attacker-controlled XML should use a secure parser configuration.
Can SVG files cause XXE?
Potentially. SVG is XML-based, so an application that parses uploaded SVG files can expose XML parser functionality. SVG upload and conversion pipelines should therefore be included in security testing.
What is CWE-611?
CWE-611 is MITRE’s classification for Improper Restriction of XML External Entity Reference. It describes software that processes XML containing external entities without adequately restricting where those entities can resolve.
External Resources
For detailed defensive guidance, the OWASP XML External Entity Prevention Cheat Sheet covers secure XML parser configuration and prevention strategies.
The MITRE CWE-611 reference provides the formal weakness definition, consequences, detection methods, and observed vulnerability examples.
Security professionals can also use PortSwigger’s XXE Web Security Academy material to understand XML entities and practice XXE in controlled labs.
Conclusion
XML External Entity attacks demonstrate why secure parsing is just as important as secure application code.
An XML document may look like ordinary structured data, but XML parsers can support features that cause external resources to be loaded and incorporated during processing. If those features are enabled unnecessarily, attacker-controlled XML can potentially access local resources, trigger network requests, or consume excessive system resources.
For developers, the most important lesson is straightforward: disable DTDs and external entity processing unless the application genuinely requires them. Secure parser configuration should be combined with input limits, dependency updates, restricted network access, and proper application testing.
For penetration testers, XXE testing should go beyond looking for one payload. The real objective is understanding the complete XML-processing chain, identifying the parser behavior, determining whether external resources are resolved, and carefully assessing the resulting impact.
If you’re building practical web application security skills, explore “https://pentesthint.com/” PentestHint for cybersecurity resources and “https://vuln.pentesthint.com/” hands-on labs for controlled vulnerability testing.
