Product overview

See how dev-centric DAST for the enterprise secures your business.

Web attacks

Continuous security testing for web applications at high-scale.

API attacks

Safeguard your APIs no matter how often you deploy.

Business logic attacks

Future-proof your security testing with green-flow exploitation testing.

LLM attacks

Next-gen security testing for LLM & Gen AI powered applications and add-ons.

Interfaces & extensions

Security testing throughout the SDLC - in your team’s native stack.


Connecting your security stack & resolution processes seamlessly.


Getting started with Bright and implementing it in your enterprise stack.

Book a demo

We’ll show you how Bright’s DAST can secure your security posture.


Check out or insights & deep dives into the world of security testing.

Webinars & events

Upcoming & on-demand events and webinars from security experts.


Getting started with Bright and implementing it in your enterprise stack.

Case studies

Dive into DAST success stories from Bright customers.


Download whitepapers & research on hot topics in the security field.

About us

Who we are, where we came from, and our Bright vision for the future.


Bright news hot off the press.

Webinars & events

Upcoming & on-demand events and webinars from security experts.

We're hiring

Want to join the Bright team? See our open possitions.

Bug bounty

Found a security issue or vulnerability we should hear about? Let us know!

Contact us

Need some help getting started? Looking to collaborate? Talk to us.

Resources > Blog >
What Is XML External Entity (XXE)? The Complete Guide

What Is XML External Entity (XXE)? The Complete Guide

Admir Dizdar

What Is an XXE Attack?

XXE (XML External Entity Injection) is a common web-based security vulnerability that enables an attacker to interfere with the processing of XML data within a web application. When exploited, XXE can allow attackers to access sensitive data, execute remote code, or interfere with the processing of XML data within a web application. 

XXE is achieved through custom XML entities that load their defined values from outside of the Document Type Definition (DTD) in which they are declared. This is important from a security perspective because it allows an entity to be defined based on the contents of a file path or URL, enabling attackers to access local files and URLs on a local network, or execute remote code.

To perform an XXE attack, the attacker needs to: 

  • Define an external XML entity with the target URL they want to reach from the server.
  • Use this entity in a data value.

To mitigate XXE attacks, you can:

  • Manually disable DTDs, by configuring XML parsers in applications to disable custom document type definitions (DTDs). 
  • Prevent developers from using XML external entities in XML content from untrusted sources.
  • Disable the processing of external DTDs, or restrict developers to static, local DTDs.

This is part of an extensive series of guides about application security

xxe vulnerability

In this article:

XML External Entity (XXE) Attack Types with Code Examples

Billion Laughs Attack

Consider a web application that accepts XML input and outputs the result. A request would look like this:

RequestPOST HTTP/1.1
Hello and welcome to my website!
ResponseHTTP/1.0 200 OK

Hello and welcome to my website!

XML documents can have a specific type, which can be defined using two standards – XSD and DTD. XML documents defined using a DTD are vulnerable to XXE attacks. 

See the following example, which uses a DTD called mytype. This DTD defines an XML entity called name. When this element is called in the HTML output, the XML parser reads the DTD and replaces it with a value.

RequestPOST HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE mytype [  
<!ELEMENT mytype ANY>  
<!ENTITY name "John">
Hello &name; and welcome to my website!
ResponseHTTP/1.0 200 OK 

Hello John and welcome to my website!

Now let’s see how an attacker can carry the so-called “billion laughs attack”. If the XML parser does not limit the amount of memory it can use, this attack uses a recursive technique to overload its memory. 

RequestPOST HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE mytype [  
<!ELEMENT mytype ANY>  
<!ENTITY name "John ">  
<!ENTITY name2 "&name;&name;">  
<!ENTITY name3 "&name2;&name2;&name2;&name2;">  
<!ENTITY name4 "&name3;&name3;&name3;&name3;">]>
Hello &t3;
HTTP/1.0 200 OK 

Hello John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John John

In essence, this is a type of denial of service (DoS) attack that can deny access to an application relying on an XML parser.


Now let’s see how a similar attack can be used to perform server side request forgery (SSRF). 

Here the attacker uses XML entities from external sources. When this happens, XXE becomes a server side request forgery (SSRF) attack.

An attacker can run a system command using an XML system identifier. Most XML parsers process external entities by default, and as a result, the server runs the system code in the malicious XML element. 

The following code shows how XXE can be used to return the contents of a sensitive file – the etc/hosts file.

RequestPOST HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE mytype [  
<!ELEMENT mytype ANY>  
<!ENTITY malicious SYSTEM  
ResponseHTTP/1.0 200 OK 

IPAddress     Hostname    Alias   localhost    web mail

This attack can be extended to gain access to other files on the server, beyond system files. Some XML parsers make it possible to retrieve directory listings and use them to find other sensitive data on the machine.

Limitations of XXE SSRF attacks

XXE attacks are limited to obtaining files that contain plain text or valid XML. They cannot be used to obtain binary files, or files that contain code that is similar to XML, but in fact is not valid XML. This will return a parser error and the attacker will not be able to view their content. 

Related content: Read our guide to Server Side Request Forgery

Blind XXE Vulnerability

A blind XXE vulnerability means that the application does process external XML entities in an unsecure way, but does not return those entities in its responses. This means attackers will need to use advanced techniques to detect the vulnerability and exploit it. 

Attackers can still exfiltrate data using blind XXE, for example by causing the server to connect to a URL controlled by the attacker. 

How to Prevent XXE Vulnerabilities

Although a common vulnerability, preventing XXE attacks can be easily achieved with good coding practices and some language-specific advice.

XXE Vulnerability in Java

Java inherently makes a programmer’s task of defending against XXE less definive, due to the reliance on parsers. Java XML parsers are often vulnerable to XXE attacks, resulting in less control in securing your applications.

Thankfully, creators of these parsers are wise to this issue, actively ensuring that they are updated accordingly to be more secure, but you are still reliant on these third parties. Some of the most common XML parsers for Java include: 

  • Dom Parser
  • SAX Parser
  • JDOM Parser
  • DOM4J Parser
  • StAX Parser

When relying on third party parsers, you should disable DOCTYPES, which will automatically protect you from XXE attacks. 

Learn more in our detailed guide to xxe attack.

XXE Vulnerability in PHP

PHP holds the title of perhaps the most popular back-end web application language, and as such, is a primary target for attackers, including XXE attacks. With attackers routinely finding new vulnerabilities, it is imperative to keep your PHP version up to date to secure your applications. 

In relation to XXE prevention, there are things that you can do in order to ensure you’re a victim. Since PHP version 8.0.0, it is highly recommended that you use libxml_disable_entity_loader. Further information on fully undersanding and implementing this functionality in your code can be found here

XXE Vulnerability in Python

Python’s popularity is growing each day with both new programmers and seasoned veterans. However, with rapid growth and expansion comes risk.

The first step in securing your Python applications is ensuring that the XML parsers you are using are safe. Some, such as Etree, Minidom, Xmlrpc, and Genshi are built with security in mind, resistant to XXE vulnerabilities. However, other popular modules such as Pulldom and Lxlm aren’t inherently safe, and precaution is advised.

Additional Prevention Tips

Here are a few general guidelines that can help you prevent XXE:

  • Manually disable DTDs – configure XML parsers in your applications to disable custom and external document type definitions (DTDs). Most applications don’t use DTDs, so this should not hurt any functionality, but can prevent XXE attacks.
  • Avoid using untrusted XML entities – make sure developers don’t incorporate XML external entities in XML content unless they come from a trusted source. This requires training and a mechanism to determine which sources can be trusted.
  • Only use local DTDs – ensure developers only use static, local DTDs. This may require training the development team and configuring the parsers not to accept other DTDs.
  • Instrument your application server – insert checkpoints in specific parts of your code to monitor runtime execution, and detect and block classes related to XML processing. This can deal with XML parsers you missed somewhere in your application code, and can prevent the most severe XXE exploits which lead to remote code execution.
  • Use security tools – Web Application Firewalls (WAF) have built-in rules that can block obvious XXE inputs. Dynamic Application Security Testing (DAST) tools can scan for XXE vulnerabilities early in the development process and suggest how to remediate them.
  • Harden configuration against XXE – the regular application hardening best practices will also be effective against XXE. Limit permissions, validate all inputs to ensure they do not reach XML parsing logic, handle errors, use authentication and encryption, limit outbound traffic, and limit DNS communications.

Learn more in our detailed guide to XXE prevention

Real-Life Examples of XXE Vulnerability

Here are some real-life examples of XXE vulnerabilities:

  • Android development tools – some of the most popular Android development tools include Android Studio, Eclipse and APKTool. They all parse XML in a way that allow attackers to gain access through external entities, creating a huge exploit in these apps. Obviously, this was patched in later versions, but it serves as a good reminder that one can never be complacent when it comes to security in development, even when relying on industry leading third party tools.
  • WordPress – XXE vulnerabilities occurred in WordPress as well. This is especially alarming given approximately 40% of all websites use this CMS provider. 

XXE Protection with Bright

Bright Dynamic Application Security Testing (DAST) helps automate the detection and remediation of many vulnerabilities including XXE, early in the development process, across web applications and APIs. 

By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. Bright completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle. 

Scan any web app, or REST, SOAP and GraphQL APIs to prevent XXE vulnerabilities – try Bright free

See Additional Guides on Key Application Security Topics

Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of application security.

API Security

Authored by Bright Security

Vulnerability Management

Authored by Bright Security


Authored by Bright Security


DORA: Exploring The Path to Financial Institutions’ Resilience

DORA (Digital Operational Resilience Act) is the latest addition to the EU regulatory arsenal. A framework designed to bolster the cyber resilience of financial entities operating within the EU. But let’s face it: there’s no lack of regulations issued by the European Union legislature, and they’re not exactly known for keeping things light and easy.

IASTless IAST – The SAST to DAST Bridge

Streamline appsec with IASTless IAST. Simplify deployment, enhance accuracy, and boost your security posture by combining SAST and Bright’s DAST.

Bringing DAST security to AI-generated code

AI-generated code is basically the holy grail of developer tools of this decade. Think back to just over two years ago; every third article discussed how there weren’t enough engineers to answer demand; some companies even offered coding training for candidates wanting to make a career change. The demand for software and hardware innovation was

Get our newsletter