Response Body Encoding

Chatter REST API serves user-submitted content that is often not filtered at input and may come from many different sources including third-party mobile and web applications. Therefore, developers creating applications that consume Chatter REST API output must take care to properly process the output for the context in which they use the data. Failing to do so may expose their application and their users to Cross Site Scripting (XSS) exploits and other problems that may result in data loss, application failure and exposure of confidential company information.

Chatter REST API strings are minimally HTML entity encoded by default, which is suitable in most cases for display between HTML tags, but not necessarily in other HTML contexts.Chatter REST API output may be used in many contexts. Developers should not assume that the default entity encoding is appropriate for all contexts.  In particular, using Chatter REST API output inside HTML attribute values, inside URLs, with javascript, inside script tags and inside CSS all require different encoding and whitelisting.  See the Open Web Application Security Project for information on how to handle API output in different contexts.

For non-HTML contexts, such as native mobile applications, Chatter REST API clients may request raw (unencoded) output by setting the X-Chatter-Entity-Encoding HTTP header in your request to false.

Chatter REST API does special encoding of any URL values included in response payloads. The main part of the URL is URL-encoded as per RFC2396, and the query string is HTML-form encoded. This encoding cannot be turned off.