In this series, we walk you through the OWASP Top 10 — the ten most common and most dangerous types of cyber attack. There’s still a lot of confusion about how these techniques actually work and what you can do about them, and most of what you find online is written for specialists rather than for the rest of us. At Rootsec, we’d like to change that, with clear explanations and no avalanche of jargon. In this article, we tackle a vulnerability with a slightly intimidating name: XML External Entities, usually shortened to XXE.

A quick note on the OWASP Top 10. XXE had its own spot in the OWASP Top 10 of 2017, listed as A4: XML External Entities (XXE). In the current edition — the OWASP Top 10 (2021) — XXE is no longer a standalone category. It has been folded into A05: Security Misconfiguration, because at its heart XXE comes down to an XML parser that has been left configured in an unsafe way. The risk hasn’t gone away; it’s simply been grouped with a broader family of configuration problems. So although you’ll still hear people say “XXE”, it now lives under the misconfiguration banner.

What are XML External Entities (XXE)?

To understand XXE, it helps to know a little about XML. XML stands for “Extensible Markup Language”, and it’s a way of structuring data using elements and attributes so that both people and computers can read it. It’s a language you never really need to learn yourself — it quietly works in the background to keep information organised and readable. Plenty of applications use XML to exchange data, from web forms and documents to messages passed between systems.

XML has a handy feature that, unfortunately, is also where the trouble starts: it lets you define your own entities — essentially shortcuts that the parser will expand into a value. One form of this lets an entity point to an external source, using syntax along these lines:

<!ENTITY example SYSTEM "URI/URL">

In everyday use, that external reference might point to a legitimate resource. The problem is that, if the application reads XML without proper restrictions, an attacker can supply their own XML and change what that reference points to. Instead of an innocent value, they can aim it at a local file on the server — or at an internal address the server can reach. When the parser dutifully expands the entity, it pulls in that file or response and may hand it straight back to the attacker. That’s an XXE attack: abusing the way an application reads XML to make it fetch things it was never meant to expose, such as configuration files or even administrative credentials.

What are the consequences of an XXE attack?

XXE is dangerous precisely because it turns a trusted feature into a doorway. The impact can include:

  • Theft of sensitive data — reading files from the server, such as configuration files or stored passwords.
  • Exposure of internal structure — revealing details about systems and services behind the scenes that an attacker can use to plan their next move.
  • Denial-of-service (DoS) attacks — crafting XML that overwhelms the parser and knocks the application offline.
  • Reaching internal systems — using the server as a stepping stone to send requests to resources that aren’t meant to be reachable from the outside.

In short, a single overlooked setting in how XML is processed can give an attacker a surprising amount of reach.

How to protect against an XML External Entities (XXE) attack

The good news is that XXE is very preventable, and the fixes are well understood.

Where you have the choice, consider whether you even need XML. For many tasks, a simpler data format such as JSON does the job without the entity feature that makes XXE possible. Moving away from XML, where it’s practical, removes the problem at the source.

When XML is genuinely needed, the key is to configure your XML parser safely. That means disabling support for external entities (and document type definitions, where they aren’t required) so that the parser simply refuses to fetch external resources. On top of that, validating and sanitising input ensures the application isn’t blindly processing whatever XML it’s handed. These are small, deliberate settings — and they’re exactly the kind of configuration that, when missed, lands XXE in the OWASP “Security Misconfiguration” category in the first place.

The catch is that these protections only help if they’re actually switched on, and consistently so across every component that reads XML. That’s easy to assume and harder to guarantee — which is where a thorough test pays off. At Rootsec, a penetration test checks whether your applications mishandle XML and surfaces any misconfigurations before someone else finds them.

Making information security simple has always been our goal, and this series is part of that mission.

Not sure whether your applications are exposed to XXE or other misconfigurations? A Rootsec penetration test finds out before an attacker does. Book a free consultation.