Sign Up Login
Resource Center  >  Blog

XXE Prevention: XML External Entity (XXE) Attacks and How to Avoid Them

July 1, 2021
Nedim Marić

XML External Entity Injection (XXE) is one of the most common vulnerabilities. At its core, it’s a web security vulnerability where attackers target  and compromise an application’s processing of XML data. 

However, what makes XXE attacks so powerful is that they can be deployed against various programming languages, including C/C++, Java, .Net, iOS. Let’s Look at how XXE injection attacks work and what you can do to prevent them.

In this article you will learn:

How does XXE work?

Alongside JSON, XML is probably the most popular tool that developers use when working with data. While JSON is simpler to use, XML is more powerful and it’s often utilized for bigger projects that require more complex data operations. Unlike JSON, XML can also display the data as it’s a markup language. A big difference between these two is that XML requires a parser while JSON does not. It is this differentiation that leads to potential security exploits, as vulnerabilities are often introduced when creating XML parsers. 

XXE attacks can also be leveraged by an attacker to perform server-side request forgery (SSRF) attacks to compromise the underlying server.

Types of XXE

XXE attacks are a powerful method of exploiting applications, owing to the numerous ways in which in can be exploited, including:

  • Carrying out a SSRF (Server-Side Request Forgery) attack 
  • Gaining access to file contents through requesting the application’s response
  • Forcing error messages through blind XXE, and potentially displaying sensitive data in those parsing error messages

XXE Prevention in common programming languages

XXE can be prevented through smart coding practices, and we’ll go through some of the most popular programming languages where this vulnerability occurs. 

XXE Prevention in C/C++

XXE regularly shows up in C/C++. This issue occurs due to the use of Libxml2, which is an XML parser. However, the issue lies in the fact that libxml2 allows external entities by default.

Luckily, there is a way to prevent this from happening. You can install your personal entity loader via xmlSetExternalEntityLoader, which allows you to control which URLs to load, preventing any unwanted action on your application. 

XXE Prevention in Java

Hackers using XXE attacks love Java as most Java XML parsers are vulnerable to XXE, thus making life difficult for you. 

For example, one of the most popular Java parsers dom4j, used to have XXE vulnerability and it’s very likely that most Java applications are still vulnerable to it. However, you should update dom4js to at least version 2.1.3 in order to avoid this behavior and prevent XXE attacks.

Here’s an example of unsafe Java code vulnerable to XXE attack:

DocumentBuilderFactory dbf= DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();

However, this can easily be prevented by adding a snippet of code that disables DOCTYPES:

dbf.setFeature("", true);

XXE Prevention in .NET

Finally, some good news for .net developers – the XXE attack prevention is no longer an issue since version 4.5.2. While .net applications using this framework were vulnerable up until 4.5.1, this issue is now resolved and you can rest easy knowing that your applications are safe(r). 

While we’d all be using the latest versions in an ideal world, unfortunately, that’s not possible for everyone. But worry not, there’s still a solution to your problem! Perhaps the best way to keep your code safe is to simply shut down any external resources via XmlResolver.

XmlDocument xmlDocument = new XmlDocument();
xmlDocument.XmlResolver = null;

XXE Prevention in iOS

iOS developers will mostly face similar issues that C/C++ has regarding XXE attacks. Just like C/C++, iOS uses libxml2 as a parsing library. Even though libxml2 version 2.9 protects against XXE automatically, iOS6 and older use the old libxml version resulting in vulnerable code. 

This is where NSXMLDocument comes in. It’s a feature for iOS built on top of libxml2 and you can easily protect against XXE by using this command when creating a new NSXMLDocument:


XXE Prevention in PHP

As you all probably know, PHP is one of, if not the most popular server-side languages out there. It’s used in all sorts of web applications, making it a perfect target for malicious attacks.

This especially applies to XML parsing because it’s so often used with PHP. The good thing, however, is that you can create XXE attack prevention relatively easily. When using the default XML Parser with PHP, all you have to do is add the following line to your code:


This disables the ability to load external entities, keeping your application safe.

XXE Prevention in Python

Python’s popularity brings so many amazing things with it as it allows for endless modules to be created. However, this luxury often comes at the cost of security, considering the fact that many of these modules aren’t built with safety in mind. As far as XML parsing goes in Python, these are some of the most popular parsers: 

  • Pulldom
  • Lxlm
  • Sax
  • Etree
  • Genshi
  • Xmlrpc
  • Minidom

Etree, Minidom, Xmlrpc, and Genshi are secured by default and they don’t require additional action in order to protect from XXE injection. However, there is a way for each of these parsers to be secured, and that is with defusedxml. It’s fully compatible with any of the packages above, and it provides full protection against potential XXE attacks. 

Defusedxml disallows access to local or remote resources in an external entity and raises an exception any time this is attempted.

How to Test for XXE

XXE attacks pose a serious risk, but can be easily prevented by using and properly configuring a good XML parser, as well as ensuring input validation, proper error handling and minimizing filesystem permissions. Make sure you scan your applications for XXE detection and other vulnerabilities before you release them to production, ideally integrated into your development pipelines to scan every build or merge to master – Try Bright for free to achieve just that

Related Articles:

Related topics

Dynamic Application Security Testing (DAST) is a crucial component in fortifying web applications against potential vulnerabilities. By taking a proactive stance, DAST systematically detects and addresses security flaws.

See more

By mapping Dynamic Application Security Testing (DAST) to the Payment Card Industry Data Security Standard (PCI DSS) requirements, organizations can

See more

What Is Mobile Application Security Testing?  Mobile application security testing is the process of assessing, analyzing, and evaluating the security

See more

Test Your Web App for 10,000+ Attacks

See Our Dynamic Application Security Testing (DAST) in Action

  • Find & fix vulnerabilities fast
  • Zero false positives
  • Developer friendly

and see how easy AppSec can be

Prevent XXE attacks now. Secure your app with every build

  • Easily and quickly find & fix security bugs

  • Automate it in your build pipeline

  • No false positives

  • Scan any target: web apps & APIs

Test Your Web App for 10,000+ Attacks

Integrate vulnerability testing into your DevOps pipeline. Find & fix vulnerabilities fast with zero false positives.
See Our Dynamic Application Security Testing (DAST) in Action
Testing variance Using Legacy Dast Using Dev-Centric Dast
% of orgs knowingly pushing vulnerable apps & APIs to prod 86% 50%
Time to remediate >Med vulns in prod 280 days <150 days
% of > Med vulns detected in CI, or earlier <5% ~55%
Dev time spent remediating vulns - Up to 60x faster
Happiness level of Engineering & AppSec teams - Significantly improved
Average cost of Data Breach (US) $7.86M $7.86M