What Is XXE (XML External Entity) Injection? How to Prevent It
XXE is when an application processes XML insecurely, letting the attacker read server files, scan the internal network and sometimes run code. How it works, a types table, disabling external entities and DTD, scanning with KAOS and FAQs.
Quick answer: XXE (XML External Entity injection) is when an application processes user supplied XML data insecurely, letting the attacker read files on the server, scan the internal network and in some cases run remote code. The XML format allows defining an "external entity" inside a document; if an insecure parser processes this definition, the attacker can make the application read a file from their server or the local system. For example, an external entity can be defined to point at the server's password file. The root fix is one sentence: disable external entity and DTD processing in the XML parser.
XXE is a classic member of the OWASP Top 10 and appears wherever XML is used, in SOAP services, file upload flows and even some document formats. The logic is simple: the application trusts XML too much. This article explains how XXE works, which defenses actually help and how it is tested.
How XXE works
XML documents can define "entities" in a section called the DTD (Document Type Definition). An entity is a placeholder used like an abbreviation inside the document. The problem is that an entity can be defined to point at an external resource (a file path or an address). When an insecure parser resolves this external entity, it:
- Reads a local file on the server and reflects its content in the response.
- Makes the application send a request to an internal address chosen by the attacker. Combined with SSRF, this targets the internal network.
- Exhausts memory with many nested entity definitions and stops the service.
The key point: the application thinks the XML is just "data," but the insecure parser runs it like a "to-do list."
Types of XXE
| Type | Symptom | Impact |
|---|---|---|
| Classic (reflected) | File content appears in the response | Information disclosure |
| Blind | Output invisible but entity resolves | Out of band data exfiltration |
| Via SSRF | Request goes to an internal address | Internal network discovery |
| Denial of service | Nested entity bomb | Server crash |
Blind XXE is especially dangerous: even if output is invisible, the attacker can craft the external entity to send data to their own server and exfiltrate file content.
Proper defense
1. Disable external entity and DTD processing
This is the strongest and most definitive defense. External entity resolution and DTD processing must be disabled in the XML parser the application uses. Most XML libraries support this setting; when disabled, XXE becomes impossible at the root.
2. Prefer a simpler format when possible
In new development, choosing simpler data formats over complex XML removes the XXE surface entirely. For existing XML endpoints, parser hardening is essential.
3. Input validation and least privilege
Endpoints accepting XML must be validated strictly, and the account the application runs under should only reach files it needs. So even if a flaw exists, the reachable area is narrowed.
4. Keep libraries up to date
Old XML libraries may ship with insecure defaults. Current versions mostly disable external entities by default; this is part of managing security misconfiguration.
XXE scanning with KAOS
We scan for XXE flaws on XML accepting endpoints at scale with KAOS, DSET's AI powered autonomous security scanning engine. With its multi agent architecture KAOS discovers endpoints that process XML, tries with a controlled, harmless payload whether external entity resolution is enabled, and when it can show it reaches a file or receives an out of band signal it verifies this; it reports only proven findings. So instead of the false positive pile of classic scanners you get few but real findings. KAOS works alongside the human expert, not in their place, and documents every finding with a working proof.
Frequently asked questions
Does XXE only read files? No. Besides reading files it can make internal requests (SSRF), stop the service and, in some configurations, lead to code execution.
Am I at risk if I do not use XML? Even if you do not take XML directly, some document and file formats use XML internally. Endpoints processing these files can also be exposed to XXE.
Does disabling external entities break anything? Most applications do not use external entities; disabling does not break functionality, it only turns off the dangerous feature. That is the secure default.
How is blind XXE noticed? Even if output is invisible, the external entity is crafted to make a request to the attacker's server; the incoming request proves the flaw.
Sources
- OWASP, XML External Entity Prevention Cheat Sheet: https://cheatsheetseries.owasp.org
- OWASP, XXE: https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing
- MITRE, CWE 611: https://cwe.mitre.org/data/definitions/611.html
- PortSwigger Web Security Academy, XXE: https://portswigger.net/web-security/xxe
To detect XXE and XML processing flaws in your application with a working proof from KAOS and our expert team, contact DSET. From our Ankara Hacettepe Teknokent laboratory we provide penetration testing and secure code review.
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.