Unlike a lot of other mistakes that we've reviewed during this course that can cause unexpected bugs or maybe a bad user experience, the mistake that we're going to look at in this video is actually a downright security hazard. So make sure you're listening well. Now that I've got your attention, what exactly are we talking about? Well, let's take a few minutes to look at the HTML.
This powerful directive allows us to define HTML as reactive data and then render it to the page. You might think this is a perfect solution then for something like supporting rich text in the comment section of your blog. However, there is a big issue at play here, and its name is JavaScript injection. Let me show you what I mean by that.
So, sure, over here now I can provide some nice rich text whenever I create a new comment. Let's say I said I had a paragraph tag, hello, and then I wanted to make world stand out. So I wrap it in a strong tag. Great.
Let me copy that, and then I will submit it. Of course, my new comment looks great. It's exactly what we expect. However, let's say someone malicious stumbles onto our site and they want to, I don't know, redirect this page to some malicious page of their choosing.
It doesn't matter where. Well, all they would have to do now is they could provide a legitimate comment, but then along with their legitimate comment, They could do something like provide an image tag. And let's say that the source of that image is some cat picture. It doesn't really matter.
It's just any image whatsoever. I happen to find this cute little guy on Google. So we'll use that URL. Great.
Then we close out the image tag, and here comes the kicker. The user can now say, I want to, whenever the image loads, redirect the page to a URL of my choice. We aren't nasty people, though. com.
I will copy that and now I will hit submit. com. Now imagine I have stored this comment in my database and I push that comment to the front end. I load that comment in the front end for every new user who visits my blog post.
com. Just to prove it to you, we'll hard code in the text that I just copied. This now is coming from my database, you could say. And now whenever I visit my dev server, sure enough, immediately I get redirected to Google.
Now there's no telling what some people could end up doing with this. Maybe they don't redirect the page on load. Maybe they actually read the cookie for the website. Maybe it's a logged in area of your website and they read some kind of user cookie, send it off via a fetch request to their own API endpoints.
So they're gathering session data about your users. Any possibility here is on the table because they can execute JavaScript at will. So, Yes, VHTML has its use cases. If the inputs for your site, so if the comments, essentially this data here, is always going to be from a trusted source, then using VHTML is fine.
However, if it's from an untrusted source, if it's just from any user on your website, make sure you're either sanitizing the data or you're avoiding VHTML altogether.