I found out why innerHTML is dangerous.

When we first learn JavaScript, the innerHTML property seems like the ultimate tool. It provides a highly convenient way to dynamically update the Document Object Model (DOM) by assigning a string of HTML directly to an element. However, as we transition from basic scripts to production-level applications, we quickly learn that using innerHTML introduces a critical security vulnerability: Cross-Site Scripting (XSS).

The fundamental flaw of innerHTML lies in how the browser parses the data. When you pass a string to this property, the browser's HTML parser completely processes it, converting any HTML tags into actual DOM nodes. If that string contains unsanitized user input—such as a comment on a blog or a profile name—a malicious actor can easily inject executable code into the application.

For example, a standard script injection might look like this:

const userComment = "<img src='missing.jpg' onerror='stealCookies()'>";
                document.getElementById('comments-section').innerHTML = userComment;

Because innerHTML parses the <img> tag, the browser will attempt to load the broken image, trigger the onerror event handler, and silently execute the attacker's stealCookies() function. This is known as a DOM-based XSS attack. Once an attacker can run arbitrary JavaScript in the victim's browser, they can hijack session tokens, perform unauthorized API requests, or completely deface the application interface.

To mitigate this risk, modern web development best practices dictate that we should avoid innerHTML whenever handling dynamic user data. If we only need to update the text of an element, we should always use the textContent property instead. Unlike innerHTML, textContent treats all input as raw text and automatically encodes special characters, rendering any injected <script> tags completely harmless.

If an assignment or project absolutely requires us to render raw HTML strings from a database, we must sanitize the input first. We can accomplish this by using established sanitization libraries, such as DOMPurify, which systematically strip out dangerous attributes and tags before they ever reach the DOM. Alternatively, constructing the DOM manually using document.createElement() and Node.appendChild() ensures that data is treated safely as node text rather than executable markup.

Ultimately, while innerHTML is an easy shortcut for beginners, it is simply not worth the security trade-off. Writing secure code requires us to default to safer alternatives like textContent to ensure our applications remain resilient against XSS attacks.