I've been doing some experimenting with innerHTML to try and figure out where I need to tighten up security on a webapp I'm working on, and I ran into an interesting injection method on the mozilla docs that I hadn't thought about.
var name = "<img src=x onerror=alert(1)>";
element.innerHTML = name; // Instantly runs code.
It made me wonder a.) if I should be using innerHTML at all, and b.) if it's not a concern, why I've been avoiding other code insertion methods, particularly eval.
Let's assume I'm running javascript clientside on the browser, and I'm taking necessary precautions to avoid exposing any sensitive information in easily accessible functions, and I've gotten to some arbitrarily designated point where I've decided innerHTML is not a security risk, and I've optimized my code to the point where I'm not necessarily worried about a very minor performance hit...
Am I creating any additional problems by using eval? Are there other security concerns other than pure code injection?
Or alternatively, is innerHTML something that I should show the same amount of care with? Is it similarly dangerous?
'innerHTML' Presents a Security RiskThe use of innerHTML creates a potential security risk for your website. Malicious users can use cross-site scripting (XSS) to add malicious client-side scripts that steal private user information stored in session cookies. You can read the MDN documentation on innerHTML .
To avoid the automatic encoding of React, the developer has to assign the data to the innerHTML attribute directly. However, doing so carelessly will cause XSS vulnerabilities. That's why React exposes the innerHTML attribute through the dangerouslySetInnerHTML property.
Yes, you are correct in your assumption.
Setting innerHTML
is susceptible to XSS attacks if you're adding untrusted code.
(If you're adding your code though, that's less of a problem)
Consider using textContent
if you want to add text that users added, it'll escape it.
innerHTML
sets the HTML content of a DOM node. When you set the content of a DOM node to an arbitrary string, you're vulnerable to XSS if you accept user input.
For example, if you set the innerHTML
of a node based on the input of a user from a GET
parameter. "User A" can send "User B" a version of your page with the HTML saying "steal the user's data and send it to me via AJAX".
See this question here for more information.
What you might want to consider if you're setting the HTML of nodes is:
textContent
to set the text of nodes manuallySee this question on more general approaches to prevent XSS.
Code injection is a problem. You don't want to be on the receiving end.
That's not the only problem with innerHTML
and eval
. When you're changing the innerHTML
of a DOM node, you're destroying its content nodes and creating new ones instead. When you're calling eval
you're invoking the compiler.
While the main issue here is clearly un-trusted code and you said performance is less of an issue, I still feel that I must mention that the two are extremely slow to their alternatives.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With