What Is XML Injection
XML injection is a class of attack in which an attacker supplies crafted input that breaks out of its intended position within an XML document and alters the document's structure or content. When an application takes user input and inserts it into an XML document without adequate sanitisation, the attacker can add new XML elements, modify existing ones, or inject comments that change how the document is parsed and acted upon.
XML injection is distinct from XML External Entity (XXE) injection, which exploits the XML parser's external entity processing feature. XML injection operates at the document structure level — the attacker is manipulating the XML content itself rather than the parser's behaviour.
A Simple Example
Suppose an application takes a product ID submitted by a user and embeds it in an XML query sent to a back-end inventory service:
```xml <query> <productId>1234</productId> <user>customer@example.com</user> </query> ```
If the application inserts the product ID without sanitisation, an attacker can supply input like `1234</productId><admin>true</admin><productId>` to produce:
```xml <query> <productId>1234</productId><admin>true</admin><productId></productId> <user>customer@example.com</user> </query> ```
If the back-end service reads the `<admin>` element to determine access level, the attacker has escalated their own privileges.
Where XML Injection Appears
**SOAP web services** — Legacy enterprise applications and some financial services platforms communicate via SOAP, an XML-based protocol. User-controlled values passed into SOAP requests without encoding are a classic XML injection target.
**XML-based configuration or rule engines** — Applications that store rules, workflows, or configuration in XML and allow user-defined values to influence those structures.
**Search and filter functionality** — Applications that translate user search queries into XML-based query languages such as XQuery or XPath. Injecting into XPath queries is a specific sub-variant sometimes called XPath injection, and it can allow an attacker to bypass authentication or extract data from an XML data store.
**File format processing** — Applications that accept user input to populate XML-based file formats such as SVG, DOCX, or XLSX internally.
XPath Injection
XPath injection deserves specific attention. Where an application uses XPath to query an XML document — for example, to look up a user in an XML-based user store — injecting into the XPath expression can allow authentication bypass.
A login query might look like:
```xpath //users/user[username/text()='alice' and password/text()='secret'] ```
If the username field is not sanitised, submitting `alice' or '1'='1` transforms the query to:
```xpath //users/user[username/text()='alice' or '1'='1' and password/text()=''] ```
The `or '1'='1'` condition is always true, so the query returns the first user in the document — often an administrator account — regardless of the password supplied.
Impact
The impact of XML injection varies with the application's architecture:
- **Privilege escalation** — Adding elements that modify access control decisions - **Authentication bypass** — Via XPath injection against XML user stores - **Data extraction** — Injecting elements that cause the application to return data from other parts of the XML document in its response - **Denial of service** — Injecting deeply nested structures that cause the parser to consume excessive resources (sometimes called the Billion Laughs attack when combined with entity expansion)
Prevention
**Validate and whitelist input** — For values that should conform to a known format — product IDs, reference numbers, usernames — validate against a strict pattern before allowing them anywhere near XML construction.
**Encode user input before inserting into XML** — The five XML special characters (`<`, `>`, `&`, `'`, `"`) must be encoded as their entity references (`<`, `>`, `&`, `'`, `"`) before insertion into XML content. Most modern XML libraries provide this automatically when you use their API correctly.
**Use parameterised queries for XPath** — Some XPath libraries support parameterised expressions where user values are bound as typed parameters rather than concatenated into the expression string. Use these where available.
**Avoid building XML by string concatenation** — Use a proper XML library with a document object model. Assemble the document programmatically and let the library handle serialisation. String concatenation is the root cause of the majority of XML injection vulnerabilities.
**Apply least privilege to XML processing components** — The component that parses XML should have no more access to internal systems than it needs. This limits the damage if injection does occur.
XML injection sits in the same family as [SQL injection](/blog/what-is-sql-injection) and other input-based attacks — the root cause in each case is user-supplied data reaching an interpreter without proper sanitisation. The prevention principles are consistent across all of them.
Yrzo AI's automated security assessment checks for injection vulnerabilities across web application inputs, including XML-based interfaces. Results delivered in minutes at yrzoai.dev.
Find out if your website has these vulnerabilities
Yrzo AI runs 44 automated security checks and delivers a full report in under 20 minutes. Starting from £149.
Scan your website →