---
{
  "title": "XML processing security",
  "summary": "XML processing involves parsing, schemas, namespaces, transformations, and sometimes external resource resolution.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: XML Security",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

XML processing involves parsing, schemas, namespaces, transformations, and sometimes external resource resolution. Each stage has its own trust boundary and resource limits. Protecting XML input therefore requires more than checking whether a document is syntactically well formed.

## A practical example

A partner feed is parsed with controlled entity handling, checked against an approved schema, and processed under size limits. The schema and transformation resources are controlled by the application rather than selected freely by the sender.

## What to check

Review parser options, document size and nesting, trusted schema locations, and transformation behavior. Keep libraries current and test rejected inputs as well as valid business documents.

## A common pitfall

Schema validation does not automatically disable external entities or make a later transformation safe. Controls at one processing stage do not replace controls at another.

## Think it through

Can a well-formed XML document still be unsafe to process?

**Answer:** Yes. It may trigger unwanted resource resolution or excessive computation depending on parser and transformation settings.

## A well-formed document can still be unsuitable

A fictional shipping integration expects an XML message with a shipment identifier, address, and a limited number of items. Being well-formed means the document follows XML syntax. It does not establish that the values are meaningful, the message is authorized, or processing it will stay within resource limits. Treat syntax, schema, business validation, and trust as separate checks.

The parser's capabilities matter before application logic runs. External resource resolution and unnecessary document features can expand the processing boundary. Use supported secure parser settings and limit document size and complexity according to the integration's real needs. If schemas are used, control where they come from and how references are resolved.

Later transformations introduce further interpreters. XPath queries, XSLT processing, digital signatures, and output rendering each have their own security requirements. A safely parsed input does not automatically make an unsafe XPath expression or an incorrectly validated signature acceptable. Follow the document through the whole workflow.

## Define a document contract

For the shipping example, write the permitted fields, cardinality, maximum lengths, and supported encoding. Add an unknown element, duplicate identifier, and oversized item list as review cases. Explain which layer rejects each message and how a legitimate partner learns what went wrong without receiving internal stack traces.

Keep parser and transformation libraries maintained, and review changes as part of integration testing. Archived XML may be processed years after receipt by a different component, so storage location alone should not confer trust. The practical goal is a narrow, predictable document pipeline in which every interpretation step has an owner and a defined input contract. This is more durable than relying on the file extension or the fact that the sender is a business partner.

## Related concepts

- [[xxe]]
- [[xpath-injection]]
- [[input-validation]]