Input Sanitization for MuleSoft APIs: The XSS Defense

Published in

Another Integration Blog

4 min readOct 3, 2022

What is XSS?

The infamous cross site scripting is a vulnerability where the attacker injects malicious scripts. If proper input validation is not present, the data will be sent to the microservice or database. Using this, an attacker can execute malicious commands.

How to prevent?

In this article, we discuss what we can do in Mule to keep our APIs safe via input sanitization. Essentially, input sanitization filters input on arrival. When user input is received, it is filtered as strictly as possible based on what is expected. Improper sanitization of user inputs will have greater impact on the application and related infrastructure, such as SQL injection, XPath injection, and LDAP injection. This filtration has to happen at the experience layer and not the process or system layer. So how can we do that?

RAML

A strong API specification is needed to keep our APIs safe. The format of input (xml, json) has to be clearly defined to stop anything that is HTML (this is usually followed). Field wise definitions are needed to prevent any special characters in the request headers, query, and URI parameters. This can stop scripts that are put into our request shown in the above URLs.

The RAML in the example above is similar to what we widely use. We can add maxLength: 35 property to make it better, preventing a long input from being given. For our requirement, we can add pattern: ‘(?<!.)[a-bA-B]{1}[0–9]{6,10}(?!.)’ to ensure that only an alphanumeric string is present and no special characters are added here.

JSON/XML Threat Protection Policy

This policy limits the nested arrays or nested objects and field lengths. This policy is useful for protecting against DDOS attacks; however it is not a fail proof method to prevent XSS threat. The input size/length is calculated rather than the content itself.

Custom Policy

Let’s add a custom policy on top of everything, to stops any special characters. Here, the aim is to make sure no unnecessary data enters past our gateway. In this policy, we are giving a regex to control the type of input. This can be made configurable in the policy. Thereby, even if a developer misses out on the RAML, we have an organization-wide policy as a defense.

YAML File Configuration

Let’s define what we display in the policy page. The input needed from the user is the list of characters that need to be filtered out.

Template File

The regex-validator is used to check the contents of the header against the configured regex. If you are using enterprise MuleSoft then use the nexus credentials in the .m2 settings to use the HTTP “mule-http-policy-transform-extension”. Otherwise, the error message HTTP response status cannot be defined, though it wouldn’t affect the function of the policy itself.

In this example, the header is validated against a regex. This regex is dynamically obtained through policy configuration. Similar validation can be applied against params as well. The header, params, and body validation are kept separate, as validation in params cannot be the same in body.

E.g., “<” char which is part of “<script>” should be stopped but it is valid incase of XML request body.

Can we make this better for the policy UI? In place of regex, the special characters could be obtained separately or in an array. Or give the list as checkboxes and let the users select. Play Around!