Currently Plates uses the given data as-is without doing proper HTML escape, thus a perfectly safe and legal JSON data object can be turn into very unsafe HTML.
Currenlty if a developer uses the .use mapping of Plates, the data is not escaped leading to a very real risk of Cross Site Scripting (XSS) vulnerabilities. To make matters worse, the Plate documentation does not warn the developer about the issue.
The workaround is ofcourse to escape the JSON data. This is however a very ugly solution since this will reduce the reusability of the JSON and will make the JSON API rather bad for non-HTML clients. Further more good architecture promotes for the separation of concerns and thus a JSON serializer should not have to deal with issues of HTML serialization.
Other frameworks that manipulate HTML usually provide two ways of settings element text: a method that escapes the input and an other method that does not. For example, the popular jQuery library provides the .html(htmlString) and .text(textString) functions of which the first does not do escaping and the latter does.
I recommend fixing the .use mapping of Plates so that it does escaping, and providing a separate .useHTML for the current behavior (i.e. no escaping). Furthermore, the functions that set attribute values should always escape the data per the rules of attribute value escaping.
Currently Plates uses the given data as-is without doing proper HTML escape, thus a perfectly safe and legal JSON data object can be turn into very unsafe HTML.
Currenlty if a developer uses the .use mapping of Plates, the data is not escaped leading to a very real risk of Cross Site Scripting (XSS) vulnerabilities. To make matters worse, the Plate documentation does not warn the developer about the issue.
The workaround is ofcourse to escape the JSON data. This is however a very ugly solution since this will reduce the reusability of the JSON and will make the JSON API rather bad for non-HTML clients. Further more good architecture promotes for the separation of concerns and thus a JSON serializer should not have to deal with issues of HTML serialization.
Other frameworks that manipulate HTML usually provide two ways of settings element text: a method that escapes the input and an other method that does not. For example, the popular jQuery library provides the .html(htmlString) and .text(textString) functions of which the first does not do escaping and the latter does.
I recommend fixing the .use mapping of Plates so that it does escaping, and providing a separate .useHTML for the current behavior (i.e. no escaping). Furthermore, the functions that set attribute values should always escape the data per the rules of attribute value escaping.