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.)

Answer 2

Yes, a XSS attack can happen even in a service that serves only XML. If you include the following in a XML document which is loaded by the browser, the script will be executed:

<script xmlns="http://www.w3.org/1999/xhtml">alert("XSS")</script>

This can be a security vulnerability even if the service is not meant to be used in a browser. This is because an attacker can cause a victim's browser to load the XML document with the injected javascript (for example using an iframe) an run his malicious script on your site. This can have various consequences:

• If another service is running on the exact same domain, the attacker can gain access to it.
• The attacker can also set cookies for every parent domain (except TLD and some other exceptions), which might be used to attempt to exploit other servers.
• The attacker can use it for phishing to present a legitimate url in the address bar.

It's also possible that an XML injection could be used to trick some other service into doing something unexpected. Sometimes other services pass user input into APIs without any validation. A poorly written service might expose the XSS on a normal HTML website.

In any case i would advise you to fix any XSS vulnerability you find, even if you think it's not exploitable.