We have a REST API that returns user generated content from a database. Before inserting the data into the database the data is sanitized.
But when returning the data we do not escape / decode the data, so in theory it would be possible to insert some user content that will execute an attack, once it is consumed from the client.
Right now the only client is an internal one, that displays the data in some HTML frontend.
Now my question is, should the API return json escaped JSON? Or should the client make sure to html escape the received content?
I am split here in my personal opinion, in general I would return data as is from any API and let take the client care of escaping (as there could be several different clients and the API should be agnostic to its content).
On the other hand its an internal one and we know how we use it, so it could return escaped data.
Any inputs?
Best Answer
It belongs to the API to correctly serialize JSON: the user is not expected to be able to break JSON schema by introducing characters considered special in JSON, such as the quote character.
It doesn't belong to the API to HTML-encode the input: this is the responsibility of the consumer. If you HTML-encode data at the level of the API, it makes it extremely painful to use in any other context, such as a mobile application. Actually, using it even in web applications would become unnecessarily painful: React or Angular apps would require specific code to handle such strings in order to avoid double-escaping, and even outside those frameworks, the developer would have to think twice to avoid encoding strings which were already encoded.
Finally, the API should be agnostic; it is not expected to know if it is used by a PHP site, or through AJAX requests, or by a Java application, or an Android app.