Coders Conquer Security: Share & Learn Series - XXE Injection
The XML External Entity Injection attack, sometimes simply abbreviated as XXE injection, is relatively new compared with some of the classic vulnerabilities that are still making the rounds years after their inception. But it's extremely popular among hacking communities right now, and growing even more so as it racks up successes.
In fact, OWASP now lists XXE injection as one of the top ten vulnerabilities that sites need to watch out for and actively defend against. But don't worry, XXE injection isn't any more powerful than other exploits being deployed in cyberattacks. It's just a little bit newer and a little bit less understood. It can be prevented, and in fact, completely halted.
In this episode we will learn:
- How attackers use XXE injections
- Why XXE injection is dangerous
- Techniques that can prevent this vulnerability.
How do Attackers Trigger an XXE Injection?
The XXE injection vulnerability can occur when a malicious user is given the ability to submit XML code. They use this ability to create a reference to an external entity. The external reference and the code is designed to slip past an XML parser with default settings, or one with weakly configured settings.
The attacker exploits the fact that the XML standard defines the concept of an entity as a storage unit of some type, but that storage can be external or internal. Used properly, it can allow XML processors to access remote resources. More often than not, attackers use this ability to instead do things like probing the internal structure of a website, launching a denial of service attack by triggering large system processes trying to access remote resources, or even dump data from a local host to a remote one that they control " making it a good technique for exfiltrating important data like passwords or personal information contained in the XML database.
The actual code involved in the attack is often fairly simplistic, merely exploiting the entity functionality. For example, this might allow a hacker to access the master password file:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
Why is XXE Injection Dangerous?
There are a few reasons why XXE injection attacks are so dangerous, and also prevalent. For one, it's a less understood vulnerability right now. And the gains that an attacker can make by exploiting it are considerable. For one, it can allow persistent attackers to slowly map all paths in an internal network or even scan ports. Although this might take a fair amount of time, there is almost no chance that a hacker's activity will be uncovered by active defenses on the target network because they are simply sending XML code into a server that is being cleared by the trusted XML parser.
Once mapped out, attackers can use the same XXE injection techniques to capture whatever files they need, either directly stealing information or by compromising valid user credentials and using them for secondary attacks. Finally, attackers that just want to make noise and be malicious can do things like triggering denial of service attacks, ordering the application to try and access distant resources designed to bog down the system.
Eliminating the XXE Injection Vulnerability
Because of the rapid increase in XXE injection attacks, many XML parsers are starting to disable external entities, sometimes called DTDs, completely by default. For those, the key is simply not enabling that functionality.
But even parsers that allow DTDs can have that functionality disabled. In general, a statement like the following is going to be needed to completely block it, but check your local framework documentation to get the exact code needed.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Following security principles, all user input should be sanitized and validated using application-wide filters. Don't forget to include GET and POST parameters, HTTP headers, and cookies. You can also create a whitelist of specific DTDs and commands that you want the parser to process, and disallow everything else.
While whitelisting and filtering works, because of the rising number of XXE injection attacks, it is still recommended that DTD support be completely disabled if the functionality is not required.
More Information about XXE Injections
For further reading, you can take a look at what OWASP says about XXE injection attacks. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.


The XML External Entity Injection attack, sometimes simply abbreviated as XXE injection, is relatively new, but it's extremely popular among hacking communities right now, and growing even more so as it racks up successes.

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo

The XML External Entity Injection attack, sometimes simply abbreviated as XXE injection, is relatively new compared with some of the classic vulnerabilities that are still making the rounds years after their inception. But it's extremely popular among hacking communities right now, and growing even more so as it racks up successes.
In fact, OWASP now lists XXE injection as one of the top ten vulnerabilities that sites need to watch out for and actively defend against. But don't worry, XXE injection isn't any more powerful than other exploits being deployed in cyberattacks. It's just a little bit newer and a little bit less understood. It can be prevented, and in fact, completely halted.
In this episode we will learn:
- How attackers use XXE injections
- Why XXE injection is dangerous
- Techniques that can prevent this vulnerability.
How do Attackers Trigger an XXE Injection?
The XXE injection vulnerability can occur when a malicious user is given the ability to submit XML code. They use this ability to create a reference to an external entity. The external reference and the code is designed to slip past an XML parser with default settings, or one with weakly configured settings.
The attacker exploits the fact that the XML standard defines the concept of an entity as a storage unit of some type, but that storage can be external or internal. Used properly, it can allow XML processors to access remote resources. More often than not, attackers use this ability to instead do things like probing the internal structure of a website, launching a denial of service attack by triggering large system processes trying to access remote resources, or even dump data from a local host to a remote one that they control " making it a good technique for exfiltrating important data like passwords or personal information contained in the XML database.
The actual code involved in the attack is often fairly simplistic, merely exploiting the entity functionality. For example, this might allow a hacker to access the master password file:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
Why is XXE Injection Dangerous?
There are a few reasons why XXE injection attacks are so dangerous, and also prevalent. For one, it's a less understood vulnerability right now. And the gains that an attacker can make by exploiting it are considerable. For one, it can allow persistent attackers to slowly map all paths in an internal network or even scan ports. Although this might take a fair amount of time, there is almost no chance that a hacker's activity will be uncovered by active defenses on the target network because they are simply sending XML code into a server that is being cleared by the trusted XML parser.
Once mapped out, attackers can use the same XXE injection techniques to capture whatever files they need, either directly stealing information or by compromising valid user credentials and using them for secondary attacks. Finally, attackers that just want to make noise and be malicious can do things like triggering denial of service attacks, ordering the application to try and access distant resources designed to bog down the system.
Eliminating the XXE Injection Vulnerability
Because of the rapid increase in XXE injection attacks, many XML parsers are starting to disable external entities, sometimes called DTDs, completely by default. For those, the key is simply not enabling that functionality.
But even parsers that allow DTDs can have that functionality disabled. In general, a statement like the following is going to be needed to completely block it, but check your local framework documentation to get the exact code needed.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Following security principles, all user input should be sanitized and validated using application-wide filters. Don't forget to include GET and POST parameters, HTTP headers, and cookies. You can also create a whitelist of specific DTDs and commands that you want the parser to process, and disallow everything else.
While whitelisting and filtering works, because of the rising number of XXE injection attacks, it is still recommended that DTD support be completely disabled if the functionality is not required.
More Information about XXE Injections
For further reading, you can take a look at what OWASP says about XXE injection attacks. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

The XML External Entity Injection attack, sometimes simply abbreviated as XXE injection, is relatively new compared with some of the classic vulnerabilities that are still making the rounds years after their inception. But it's extremely popular among hacking communities right now, and growing even more so as it racks up successes.
In fact, OWASP now lists XXE injection as one of the top ten vulnerabilities that sites need to watch out for and actively defend against. But don't worry, XXE injection isn't any more powerful than other exploits being deployed in cyberattacks. It's just a little bit newer and a little bit less understood. It can be prevented, and in fact, completely halted.
In this episode we will learn:
- How attackers use XXE injections
- Why XXE injection is dangerous
- Techniques that can prevent this vulnerability.
How do Attackers Trigger an XXE Injection?
The XXE injection vulnerability can occur when a malicious user is given the ability to submit XML code. They use this ability to create a reference to an external entity. The external reference and the code is designed to slip past an XML parser with default settings, or one with weakly configured settings.
The attacker exploits the fact that the XML standard defines the concept of an entity as a storage unit of some type, but that storage can be external or internal. Used properly, it can allow XML processors to access remote resources. More often than not, attackers use this ability to instead do things like probing the internal structure of a website, launching a denial of service attack by triggering large system processes trying to access remote resources, or even dump data from a local host to a remote one that they control " making it a good technique for exfiltrating important data like passwords or personal information contained in the XML database.
The actual code involved in the attack is often fairly simplistic, merely exploiting the entity functionality. For example, this might allow a hacker to access the master password file:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
Why is XXE Injection Dangerous?
There are a few reasons why XXE injection attacks are so dangerous, and also prevalent. For one, it's a less understood vulnerability right now. And the gains that an attacker can make by exploiting it are considerable. For one, it can allow persistent attackers to slowly map all paths in an internal network or even scan ports. Although this might take a fair amount of time, there is almost no chance that a hacker's activity will be uncovered by active defenses on the target network because they are simply sending XML code into a server that is being cleared by the trusted XML parser.
Once mapped out, attackers can use the same XXE injection techniques to capture whatever files they need, either directly stealing information or by compromising valid user credentials and using them for secondary attacks. Finally, attackers that just want to make noise and be malicious can do things like triggering denial of service attacks, ordering the application to try and access distant resources designed to bog down the system.
Eliminating the XXE Injection Vulnerability
Because of the rapid increase in XXE injection attacks, many XML parsers are starting to disable external entities, sometimes called DTDs, completely by default. For those, the key is simply not enabling that functionality.
But even parsers that allow DTDs can have that functionality disabled. In general, a statement like the following is going to be needed to completely block it, but check your local framework documentation to get the exact code needed.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Following security principles, all user input should be sanitized and validated using application-wide filters. Don't forget to include GET and POST parameters, HTTP headers, and cookies. You can also create a whitelist of specific DTDs and commands that you want the parser to process, and disallow everything else.
While whitelisting and filtering works, because of the rising number of XXE injection attacks, it is still recommended that DTD support be completely disabled if the functionality is not required.
More Information about XXE Injections
For further reading, you can take a look at what OWASP says about XXE injection attacks. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoThe XML External Entity Injection attack, sometimes simply abbreviated as XXE injection, is relatively new compared with some of the classic vulnerabilities that are still making the rounds years after their inception. But it's extremely popular among hacking communities right now, and growing even more so as it racks up successes.
In fact, OWASP now lists XXE injection as one of the top ten vulnerabilities that sites need to watch out for and actively defend against. But don't worry, XXE injection isn't any more powerful than other exploits being deployed in cyberattacks. It's just a little bit newer and a little bit less understood. It can be prevented, and in fact, completely halted.
In this episode we will learn:
- How attackers use XXE injections
- Why XXE injection is dangerous
- Techniques that can prevent this vulnerability.
How do Attackers Trigger an XXE Injection?
The XXE injection vulnerability can occur when a malicious user is given the ability to submit XML code. They use this ability to create a reference to an external entity. The external reference and the code is designed to slip past an XML parser with default settings, or one with weakly configured settings.
The attacker exploits the fact that the XML standard defines the concept of an entity as a storage unit of some type, but that storage can be external or internal. Used properly, it can allow XML processors to access remote resources. More often than not, attackers use this ability to instead do things like probing the internal structure of a website, launching a denial of service attack by triggering large system processes trying to access remote resources, or even dump data from a local host to a remote one that they control " making it a good technique for exfiltrating important data like passwords or personal information contained in the XML database.
The actual code involved in the attack is often fairly simplistic, merely exploiting the entity functionality. For example, this might allow a hacker to access the master password file:
<!ENTITY hackwithxxe SYSTEM file:///etc/password>
Why is XXE Injection Dangerous?
There are a few reasons why XXE injection attacks are so dangerous, and also prevalent. For one, it's a less understood vulnerability right now. And the gains that an attacker can make by exploiting it are considerable. For one, it can allow persistent attackers to slowly map all paths in an internal network or even scan ports. Although this might take a fair amount of time, there is almost no chance that a hacker's activity will be uncovered by active defenses on the target network because they are simply sending XML code into a server that is being cleared by the trusted XML parser.
Once mapped out, attackers can use the same XXE injection techniques to capture whatever files they need, either directly stealing information or by compromising valid user credentials and using them for secondary attacks. Finally, attackers that just want to make noise and be malicious can do things like triggering denial of service attacks, ordering the application to try and access distant resources designed to bog down the system.
Eliminating the XXE Injection Vulnerability
Because of the rapid increase in XXE injection attacks, many XML parsers are starting to disable external entities, sometimes called DTDs, completely by default. For those, the key is simply not enabling that functionality.
But even parsers that allow DTDs can have that functionality disabled. In general, a statement like the following is going to be needed to completely block it, but check your local framework documentation to get the exact code needed.
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
Following security principles, all user input should be sanitized and validated using application-wide filters. Don't forget to include GET and POST parameters, HTTP headers, and cookies. You can also create a whitelist of specific DTDs and commands that you want the parser to process, and disallow everything else.
While whitelisting and filtering works, because of the rising number of XXE injection attacks, it is still recommended that DTD support be completely disabled if the functionality is not required.
More Information about XXE Injections
For further reading, you can take a look at what OWASP says about XXE injection attacks. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Table of contents

Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Secure by Design: Defining Best Practices, Enabling Developers and Benchmarking Preventative Security Outcomes
In this research paper, Secure Code Warrior co-founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., along with expert contributors, Chris Inglis, Former US National Cyber Director (now Strategic Advisor to Paladin Capital Group), and Devin Lynch, Senior Director, Paladin Global Institute, will reveal key findings from over twenty in-depth interviews with enterprise security leaders including CISOs, a VP of Application Security, and software security professionals.
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
Finding meaningful data on the success of Secure-by-Design initiatives is notoriously difficult. CISOs are often challenged when attempting to prove the return on investment (ROI) and business value of security program activities at both the people and company levels. Not to mention, it’s particularly difficult for enterprises to gain insights into how their organizations are benchmarked against current industry standards. The President’s National Cybersecurity Strategy challenged stakeholders to “embrace security and resilience by design.” The key to making Secure-by-Design initiatives work is not only giving developers the skills to ensure secure code, but also assuring the regulators that those skills are in place. In this presentation, we share a myriad of qualitative and quantitative data, derived from multiple primary sources, including internal data points collected from over 250,000 developers, data-driven customer insights, and public studies. Leveraging this aggregation of data points, we aim to communicate a vision of the current state of Secure-by-Design initiatives across multiple verticals. The report details why this space is currently underutilized, the significant impact a successful upskilling program can have on cybersecurity risk mitigation, and the potential to eliminate categories of vulnerabilities from a codebase.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peak of what our content catalog has to offer by topic and role.
Resources to get you started
Revealed: How the Cyber Industry Defines Secure by Design
In our latest white paper, our Co-Founders, Pieter Danhieux and Dr. Matias Madou, Ph.D., sat down with over twenty enterprise security leaders, including CISOs, AppSec leaders and security professionals, to figure out the key pieces of this puzzle and uncover the reality behind the Secure by Design movement. It’s a shared ambition across the security teams, but no shared playbook.
Is Vibe Coding Going to Turn Your Codebase Into a Frat Party?
Vibe coding is like a college frat party, and AI is the centerpiece of all the festivities, the keg. It’s a lot of fun to let loose, get creative, and see where your imagination can take you, but after a few keg stands, drinking (or, using AI) in moderation is undoubtedly the safer long-term solution.