Of course, it is possible to use innerHTML without an XSS vulnerability, but it's much easier to reduce your XSS attack surface when you don't use it at all. You have to make that call for your project.
In my professional JS projects, we aren't building an end-user application, and we won't ultimately be in control, so we ban the use of innerHTML project-wide.
As an alternative, you can/should construct individual elements with createElement, and use innerText or createTextNode for the textual parts. For example:
const div1 = document.createElement('div');
div1.appendChild(document.createTextNode('It may be a pain, but this is '));
But if you find yourself doing this often... consider doing something else, like using a templating library or something. When we use this pattern at work, we're building a middle-ware library that constructs a DOM hierarchy with UI controls for something the app developer is building. It could have been done as a web component, but we just fill in an app-supplied div instead. There's not much text involved, except for labels and aria attributes, so it's not terribly burdensome. YMMV.
I have updated the contents of this blog on the source blog post to more directly address and discuss some of these concerns: alexlockhart.me/2018/07/the-vanill...
I agree, in most cases a trusted template library should be used. The point I wanted to stress in the blog post is that I think that in my opinion template literals should be the preferred method of rendering html from JavaScript, and that libraries can be layered on top of that basic scheme.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Of course, it is possible to use innerHTML without an XSS vulnerability, but it's much easier to reduce your XSS attack surface when you don't use it at all. You have to make that call for your project.
In my professional JS projects, we aren't building an end-user application, and we won't ultimately be in control, so we ban the use of innerHTML project-wide.
As an alternative, you can/should construct individual elements with createElement, and use innerText or createTextNode for the textual parts. For example:
const div1 = document.createElement('div');
div1.appendChild(document.createTextNode('It may be a pain, but this is '));
const em1 = document.createElement('em');
em1.innerText = 'worth';
div1.appendChild(em1);
div1.appendChild(document.createTextNode(' it!'));
document.body.appendChild(div1);
But if you find yourself doing this often... consider doing something else, like using a templating library or something. When we use this pattern at work, we're building a middle-ware library that constructs a DOM hierarchy with UI controls for something the app developer is building. It could have been done as a web component, but we just fill in an app-supplied div instead. There's not much text involved, except for labels and aria attributes, so it's not terribly burdensome. YMMV.
I have updated the contents of this blog on the source blog post to more directly address and discuss some of these concerns: alexlockhart.me/2018/07/the-vanill...
I agree, in most cases a trusted template library should be used. The point I wanted to stress in the blog post is that I think that in my opinion template literals should be the preferred method of rendering html from JavaScript, and that libraries can be layered on top of that basic scheme.