When I was in the initial stages of working on my first Javascript project, I used innerHTML to set the HTML markup of my games.
I used it because many lessons and tutorials on rendering objects would use this property. However, I came across an instructor who advised against using innerHTML because it was said to be a security issue. This sparked my interest and I thought that this might be an interesting topic to write about for my first blog. I did some research and uncovered that several sources indicate that one of the main disadvantages of using this element property is that it is prone to cross-site scripting because innerHTML can add text and elements to the webpage easily, and therefore it can be manipulated by attackers to display malicious or harmful elements within other HTML element tags. Cross-site scripting attacks are injections of unwelcome scripts into what would otherwise be considered agreeable and trustworthy websites. A web application's output can be compromised by these attacks due to widespread flaws where input from the user is not validated or encoded before it is output. Sensitive information may be lost, leaked, or altered as a result, which could be incredibly devastating to the user. A great deal of damage could be inflicted on a person's life as such access could result in identity fraud, among other things.
The following example may appear to be a cross-site scripting attack, but the result is harmless since HTML specifies not to execute script tags inserted with innerHTML.
But there are other ways to execute JavaScript without using script elements, so using innerHTML to set strings over which you have no control still poses a security risk.
It is recommended instead, that in place of innerHTML, programmers use either setHTML() or textContent. A string of HTML can be parsed and sanitized using the setHTML() method of the Element interface and then inserted into the DOM as a subtree. Plain text can be inserted using textContent, which does not parse it as HTML but inserts it as raw text.
Though I figured my project's security wasn't something I needed to concern myself with as it doesn't require any sensitive information, and therefore wouldn't pose any issues, I thought it was best to get into the habit of not using that element property early on as it could become an old habit that might be hard to break and I don't want to become too reliant on it. So I decided to discard my innerHTML code and instead start out using a combination of methods such as querySelector, append, and createElement. When querySelector() is invoked on a document, it returns the first Element matching the specified selector or group of selectors. After the last child of the Element, the append() method inserts a collection of Node objects or string objects. When createElement() is called on an HTML document, an HTML element specified by tagName will be created in the document, or if the tagName isn't recognized, an HTMLUnknownElement will be created. I then used textContent to set the text.
The innerHTML property is also said to have numerous other faulty traits:
It is much slower to use innerHTML since it builds its
contents slowly and it re-parses already parsed elements
and contents. This is time-consuming. This isn’t ideal
when most users don’t like having to wait longer than a
a couple of seconds for the content to load.The event handlers will not get attached to the new
elements created by setting innerHTML automatically.
They will be preserved. Therefore, to accomplish attaching
them to new elements, one must manually attach the event
handlers to the new elements, which requires one to keep
track of them. Some browsers may experience memory leaks as
a result.Inserting, appending, deleting, or changing the content of
a webpage will result in all the content being replaced and
the element's DOM nodes are re-parsed and recreated.A Javascript document can be broken by using any valid HTML
code since innerHTML provides no validation. HTML can be
used even if it is broken, which can lead to unexpected
problems.
Ultimately, the decision to use innerHTML or not is entirely up to the programmer. But it seems advisable that its usage should be within reason and entirely dependent on the type of application being built and whether or not the application will require users to provide sensitive information such as passwords, names, addresses, financial and medical information, social security, or any other sort of identifying information. If you are unsure about the vulnerability of your code, security reviews of the code are an excellent way to find flaws and locate all the places where input from HTTP requests might be incorporated into HTML.
Resources:
https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML
https://owasp.org/www-community/attacks/xss/
https://www.geeksforgeeks.org/what-is-the-disadvantage-of-using-innerhtml-in-javascript/
https://www.freepik.com/free-photos-vectors/computer-hacker
https://spanning.com/blog/cross-site-scripting-web-based-application-security-part-3/
https://developer.mozilla.org/en-US/docs/Web/API/Element/setHTML
https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent
https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector
https://developer.mozilla.org/en-US/docs/Web/API/Element/append
https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement
Top comments (0)