Tuleap is using Vue more and more frequently which is not that bad from a security point of view. This kind of modern web framework makes harder for the developers to introduce XSS vulnerabilities.

Unfortunately there are a few places in Tuleap where a user can manipulate HTML code directly and it is needed to render it inside a Vue app forcing us to use the unsafe v-html directive [0]. In this situation the developer is supposed to sanitize the value being given to the v-html directive but we had a few close calls recently where the value was used directly without any sanitization.

So to reduce the likelihood of ending up with a XSS due to a missing sanitization in v-html directive, I played a bit and ended up with a Vue plugin. This plugin, vue-dompurify-html [1], proposes a drop-in replacement of the v-html directive but it forces the value to be sanitized by DOMPurify [2].
They are multiple goals here:
* make it easier to do the right thing for the developers: besides telling Vue to use the plugin at the instantiation of the app, the new directive can be used directly. There is no need of defining a new computed properties to sanize the value which means less boilerplate code.
* reduce the number of points to inspect: only the directive/plugin code (and potentially a custom config at the init of the Vue app) instead of all the usages of v-html and the computed props associated with them.


It's outside the scope of this request but we should also works on making it more difficult to use the v-html to introduce a path of least resistance to the safer alternative. We already have an ESLint rule checking that v-html is not used. We should enforce it in the CI pipeline and make it harder to disable.



[0] https://vuejs.org/v2/guide/syntax.html#Raw-HTML
[1] https://github.com/LeSuisse/vue-dompurify-html
[2] https://github.com/cure53/DOMPurify