Injection Prevention Cheat Sheet in Java

Jump to: navigation, search

Last revision (mm/dd/yy): 11/24/2017


This document has for objective to provide some tips to handle Injection into Java application code.

Sample codes used in tips are located here.

What is Injection ?

Injection in OWASP Top 10 is defined as following:

Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.

General advices to prevent Injection

The following point can be applied, in a general way, to prevent Injection issue:

  1. Apply Input Validation (using whitelist approach) combined with Output Sanitizing+Escaping on user input/output.
  2. If you need to interact with system, try to use API features provided by your technology stack (Java / .Net / PHP...) instead of building command.

Additional advices are provided on this cheatsheet.

Specific Injection types

Examples in this section will be provided in Java technology (see Maven project associated) but advices are applicable to others technologies like .Net / PHP / Ruby / Python...



Injection of this type occur when the application use untrusted user input to build a SQL query using a String and execute it.

How to prevent

Use 'Query Parameterization in order to prevent injection.


/*No DB framework used here in order to show the real use of Prepared Statement from Java API*/
/*Open connection with H2 database and use it*/
String jdbcUrl = "jdbc:h2:file:" + new File(".").getAbsolutePath() + "/target/db";
try (Connection con = DriverManager.getConnection(jdbcUrl)) {

    /* Sample A: Select data using Prepared Statement*/
    String query = "select * from color where friendly_name = ?";
    List<String> colors = new ArrayList<>();
    try (PreparedStatement pStatement = con.prepareStatement(query)) {
        pStatement.setString(1, "yellow");
        try (ResultSet rSet = pStatement.executeQuery()) {
            while ( {
    Assert.assertEquals(1, colors.size());

    /* Sample B: Insert data using Prepared Statement*/
    query = "insert into color(friendly_name, red, green, blue) values(?, ?, ?, ?)";
    int insertedRecordCount;
    try (PreparedStatement pStatement = con.prepareStatement(query)) {
        pStatement.setString(1, "orange");
        pStatement.setInt(2, 239);
        pStatement.setInt(3, 125);
        pStatement.setInt(4, 11);
        insertedRecordCount = pStatement.executeUpdate();
    Assert.assertEquals(1, insertedRecordCount);

   /* Sample C: Update data using Prepared Statement*/
    query = "update color set blue = ? where friendly_name = ?";
    int updatedRecordCount;
    try (PreparedStatement pStatement = con.prepareStatement(query)) {
        pStatement.setInt(1, 10);
        pStatement.setString(2, "orange");
        updatedRecordCount = pStatement.executeUpdate();
    Assert.assertEquals(1, updatedRecordCount);

   /* Sample D: Delete data using Prepared Statement*/
    query = "delete from color where friendly_name = ?";
    int deletedRecordCount;
    try (PreparedStatement pStatement = con.prepareStatement(query)) {
        pStatement.setString(1, "orange");
        deletedRecordCount = pStatement.executeUpdate();
    Assert.assertEquals(1, deletedRecordCount);





Injection of this type occur when the application use untrusted user input to build a JPA query using a String and execute it. It's quite similar to SQL injection but here the altered language is not SQL but JPA QL.

How to prevent

Use Java Persistence Query Language Query Parameterization in order to prevent injection.


EntityManager entityManager = null;
try {
    /* Get a ref on EntityManager to access DB */
    entityManager = Persistence.createEntityManagerFactory("testJPA").createEntityManager();

    /* Define parametrized query prototype using named parameter to enhance readability */
    String queryPrototype = "select c from Color c where c.friendlyName = :colorName";

    /* Create the query, set the named parameter and execute the query */
    Query queryObject = entityManager.createQuery(queryPrototype);
    Color c = (Color) queryObject.setParameter("colorName", "yellow").getSingleResult();

    /* Ensure that the object obtained is the right one */
    Assert.assertEquals(c.getFriendlyName(), "yellow");
    Assert.assertEquals(c.getRed(), 213);
    Assert.assertEquals(c.getGreen(), 242);
    Assert.assertEquals(c.getBlue(), 26);
} finally {
    if (entityManager != null && entityManager.isOpen()) {


Operating System


Injection of this type occur when the application use untrusted user input to build a Operating System command using a String and execute it.

How to prevent

Use technology stack API in order to prevent injection.


/* The context taken is, for example, to perform a PING against a computer.
* The prevention is to use the feature provided by the Java API instead of building
* a system command as String and execute it */
InetAddress host = InetAddress.getByName("localhost");


XML: External Entity attack


Injection of this type occur when the application load the received XML stream using a XML parser instance in which the resolution of External Entity is not disabled.

How to prevent

Disable to resolution of the External Entity in the parser instance to prevent injection.


/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
// This is the PRIMARY defense. If DTDs (doctypes) are disallowed,
// almost all XML entity attacks are prevented
// Xerces 2 only -
String feature = "";
dbf.setFeature(feature, true);

// If you can't completely disable DTDs, then at least do the following:
// Xerces 1 -
// Xerces 2 -
// JDK7+ -
feature = "";
dbf.setFeature(feature, false);

// Xerces 1 -
// Xerces 2 -
// JDK7+ -
feature = "";
dbf.setFeature(feature, false);

// feature external DTDs as well
feature = "";
dbf.setFeature(feature, false);

// and these as well, per Timothy Morgan's 2014 paper: "XML Schema, DTD, and Entity Attacks"

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
//Here an org.xml.sax.SAXParseException will be throws because the XML contains a External Entity.
builder.parse(new File("src/test/resources/SampleXXE.xml"));

XML: XPath Injection


Injection of this type occur when the application use untrusted user input to build a XPath query using a String and execute it.

How to prevent

Use XPath Variable Resolver in order to prevent injection.


Variable Resolver implementation.

 * Resolver in order to define parameter for XPATH expression.
public class SimpleVariableResolver implements XPathVariableResolver {

    private final Map<QName, Object> vars = new HashMap<QName, Object>();

     * External methods to add parameter
     * @param name Parameter name
     * @param value Parameter value
    public void addVariable(QName name, Object value) {
        vars.put(name, value);

     * {@inheritDoc}
     * @see javax.xml.xpath.XPathVariableResolver#resolveVariable(javax.xml.namespace.QName)
    public Object resolveVariable(QName variableName) {
        return vars.get(variableName);

Code using it to perform XPath query.

/*Create a XML document builder factory*/
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

/*Disable External Entity resolution for differents cases*/
//Do not performed here in order to focus on variable resolver code
//but do it for production code !

/*Load XML file*/
DocumentBuilder builder = dbf.newDocumentBuilder();
Document doc = builder.parse(new File("src/test/resources/SampleXPath.xml"));

/* Create and configure parameter resolver */
String bid = "bk102";
SimpleVariableResolver variableResolver = new SimpleVariableResolver();
variableResolver.addVariable(new QName("bookId"), bid);

/*Create and configure XPATH expression*/
XPath xpath = XPathFactory.newInstance().newXPath();
XPathExpression xPathExpression = xpath.compile("//book[@id=$bookId]");

/* Apply expression on XML document */
Object nodes = xPathExpression.evaluate(doc, XPathConstants.NODESET);
NodeList nodesList = (NodeList) nodes;
Assert.assertEquals(1, nodesList.getLength());
Element book = (Element)nodesList.item(0);
Assert.assertTrue(book.getTextContent().contains("Ralls, Kim"));




Injection of this type occur when the application use untrusted user input to build a HTTP response and sent it to browser.

How to prevent

Either apply strict input validation (whitelist approach) or use output sanitizing+escaping if input validation is not possible (combine both every time is possible).


INPUT WAY: Receive data from user
Here it's recommended to use strict input validation using whitelist approach.
In fact, you ensure that only allowed characters are part of the input received.

String userInput = "You user login is owasp-user01";

/* First we check that the value contains only expected character*/
Assert.assertTrue(Pattern.matches("[a-zA-Z0-9\\s\\-]{1,50}", userInput));

/* If the first check pass then ensure that potential dangerous character that we have allowed
for business requirement are not used in a dangerous way.
For example here we have allowed the character '-', and, this can be used in SQL injection so, we
ensure that this character is not used is a continuous form.
Use the API COMMONS LANG v3 to help in String analysis...
Assert.assertEquals(0, StringUtils.countMatches(userInput.replace(" ", ""), "--"));

OUTPUT WAY: Send data to user
Here we escape + sanitize any data sent to user
Use the OWASP Java HTML Sanitizer API to handle sanitizing
Use the OWASP Java Encoder API to handle HTML tag encoding (escaping)

String outputToUser = "You <p>user login</p> is <strong>owasp-user01</strong>";
outputToUser += "<script>alert(22);</script><img src='#' onload='javascript:alert(23);'>";

/* Create a sanitizing policy that only allow tag '<p>' and '<strong>'*/
PolicyFactory policy = new HtmlPolicyBuilder().allowElements("p", "strong").toFactory();

/* Sanitize the output that will be sent to user*/
String safeOutput = policy.sanitize(outputToUser);

/* Encode HTML Tag*/
safeOutput = Encode.forHtml(safeOutput);
String finalSafeOutputExpected = "You &lt;p&gt;user login&lt;/p&gt; is &lt;strong&gt;owasp-user01&lt;/strong&gt;";
Assert.assertEquals(finalSafeOutputExpected, safeOutput);



A dedicated cheatsheet has been created.



Injection of this type occur when the application use untrusted user input to build a NoSQL API call expression.

How to prevent

As there many NoSQL database system and each one use a API for call, it's important to ensure that user input received and used to build the API call expression do not contains any character that have a special meaning in the target API syntax. This in order to avoid that it will be used to escape the initial call expression in order to create another one based on crafted user input. It's also important to not use string concatenation to build API call expression but use the API to create the expression.

Example - MongoDB

 /* Here use MongoDB as target NoSQL DB */
String userInput = "Brooklyn";

/* First ensure that the input do no contains any special characters for the current NoSQL DB call API,
here they are: ' " \ ; { } $
//Avoid regexp this time in order to made validation code more easy to read and understand...
ArrayList<String> specialCharsList = new ArrayList<String>() {{
specialCharsList.forEach(specChar -> Assert.assertFalse(userInput.contains(specChar)));
//Add also a check on input max size
Assert.assertTrue(userInput.length() <= 50);

/* Then perform query on database using API to build expression */
//Connect to the local MongoDB instance
try(MongoClient mongoClient = new MongoClient()){
    MongoDatabase db = mongoClient.getDatabase("test");
    //Use API query builder to create call expression
    //Create expression
    Bson expression = eq("borough", userInput);
    //Perform call
    FindIterable<org.bson.Document> restaurants = db.getCollection("restaurants").find(expression);
    //Verify result consistency
    restaurants.forEach(new Block<org.bson.Document>() {
        public void apply(final org.bson.Document doc) {
            String restBorough = (String)doc.get("borough");


Testing for NoSQL injection

Authors and Primary Editors

Dominique Righetto -

Other Cheatsheets