There are a few angles here:
(1) Misinterpretation of correctly-generated non-HTML response type as dangerous HTML. This is what Rook's answer is talking about, on the assumption that your REST service is returning a response such as JSON or XML. Problem here is that some browsers (in particular IE) could ignore the stated
Content-Type and treat a document as being HTML because it has some magic string like
<html in the first /n/ bytes.
A defence against this in modern browsers is to use the header
X-Content-Type-Options: nosniff, which is a good thing to do in all responses generally. To cover all cases you can use encoding rules for your format to avoid putting potentially-sensitive variable text in an encoding form that can't be misinterpreted as HTML. Typically this means writing
\u003C in JSON strings, even though
< is not normally a character that needs escaping in JSON. With XML you are covered for that as you need to encode a literal
< anyway. Other characters there are arguments for encoding (though the attacks are extremely marginal) are
(2) Incorrectly-generated response, missing correct encoding for format.
Input validation is a good defence-in-depth measure as well as a good way to enforce business rules. But it does not blanket-protect you from injection vulnerabilities. If you put together an XML or JSON response by adding strings together without explicit escaping, you've got the potential for an attacker to cause malformed responses that may get interpreted by another caller. This probably wouldn't result in direct XSS, but it could certainly cause app-specific logical problems.
Use the correct form of string encoding for your context every time you add strings together, or, better, use data output libraries that do it automatically (eg standard JSON or XML serialiser). This makes sure your response is correct, and the security is a side-effect of that correctness.
(3) XML document types. This is a mixture of (1) and (2), where injection gives you the possibility of interpreting XML as a different kind of XML. If you've got an XML-injection problem, an attacker might be able to include an element in your response with an
xmlns pointing to the XHTML or SVG namespaces. If the document is loaded directly into a web browser, these can include script content that executes in that site's origin, and there you again potentially have XSS.
(4) DOM XSS—bad client-side handling of response. If the REST response is being consumed by a web browser script that takes a value in the response and sets
innerHTML to that, you've still got an HTML-injection vulnerability, just in a slightly different place.