Can reflected XSS (cross site scripting) attack happen on a REST API which serves non HTML response

Question

Can reflected XSS (cross site scripting) attack happen on a REST API which takes in a XML request payload, serves a XML response. There is no html content in the request or response.

I have gone through quite some documentation on XSS, now I am of the opinion that this doesn't apply to a REST API which doesn't serve html content, is this understanding correct? We are however doing validation on the request received to check if there are any kind of tags (<>) in the input, & few other business level validations.

Few points about our service,

1. Our REST APIs don’ t receive or respond with HTML data.
2. We are not getting any input or request directly from an end user (possibility of an attacker comes majorly from malicious end users )
3. We are not sending XML responses directly to end users / HTML rendering system (browser) where the chances of XSS is highest.
4. We take the request & pass on the response to services internal to our enterprise & trusted (partners).
5. The XML response we send is used to just read the values embedded in a non-html env (these are trusted services that are reading our responses).

How much is the risk of an XSS in this case?

(The reason behind this query is we are getting a checkmarx high severity error where in it suggests we are prone to reflected XSS, and I am thinking this might be a false positive in our case. We are using a spring boot application.)

Answer 1

It mostly depends on the response content-type. As long as it's something like applicatiin/xml or text/xml (and not text/html or application/xhtml), the api itself is not vulnerable to xss, because a modern browser will not run the script even if displayed.

Note though that it might still be vulnerable to xml injection, and if Checkmarx found it as xss, there probably is some kind of possible injection. Make sure that it's not possible for a user to create xml tags or attributes in the response. The way to do that is very similar to how xss is prevented. Note though that you do not need to html encode user input when writing it to the xml as it's not html, but you need to xml encode values.

Also note that validating input is nice, but in general, injection attacks are prevented by context-aware output encoding, ie. applying the appropriate encoding type to values, xml attributes and so on. Many times you cannot fully achieve this on the input side. (Input validation still makes sense and you should be doing that too, but injections are best prevented by output encoding.)