The Vordel API Server ships with many samples, and one of them is a sample policy which scans XML content for threats. It includes a Threatening Content check as one of the filters used. You can see it in the screenshot below (it's the third item in the circuit):

If we double-click on the Threatening Content filter, we can see that it is using a list of attacks, including SQL injection, DTD attacks (e.g. XML Element Expansion), etc.


This is a blacklisting approach. We're checking if any of the content is on the blacklist. But often it makes sense to do whitelisting. This involves a strict check that the content is valid, so that any invalid content (e.g. an attack such as SQL Injection or Cross-Site Scripting) will simply fail the check. Here's an example of a whitelisting policy I've configured in the Vordel API Server to scan SOAP body content. There are a number of simple steps. Firstly, I am  using XPath to read in the content of the XML elements into a string (called "ContentToScan"). I'm reading in the content of the elements under the SOAP operation.


Then, I'm using a "Validate Selector Expression" filter to validate this string. You can see below that I'm validating it using a regular expression which checks that the content of the XML elements contains only alphanumeric characters or a dash ('-').


In this way, any content which does not pass this validation rule will result in this filter returning false, and therefore going down the red line in the policy execution (as opposed to the green line if it's valid). You can see the policy execution graphically in the screenshot above.

You can also combine blacklisting with whitelisting, simply by combining the two in one policy on the Vordel API Server, or calling one policy from the other using a Policy Shortcut. That gives you the best of both worlds.