¿Cómo se previene el XSS?
Respuesta breve
La defensa principal es la codificación de salida contextual — codificar los datos no confiables para el lugar exacto donde aterrizan (cuerpo HTML, atributo, JavaScript, URL). Combínalo con API DOM seguras (textContent en lugar de innerHTML), el autoescapado de los frameworks, la validación de entrada y una Content-Security-Policy como defensa en profundidad de respaldo que limita qué scripts pueden ejecutarse.
El XSS ocurre cuando datos no confiables son interpretados como código por el navegador. Toda la estrategia de prevención se deriva de un principio: mantener los datos como datos. El navegador cambia constantemente de contexto de análisis — HTML, atributos, JavaScript, CSS, URL — y cada contexto tiene caracteres distintos que permiten salir de él. Por eso la solución no es una única función mágica; es hacer la codificación correcta para el lugar correcto.
Codificación de salida contextual (el control principal)
Codifica los valores no confiables en el punto de salida, para el contexto específico:
- Cuerpo HTML → codificar en entidades HTML (
<se convierte en<). - Atributo HTML → codificar para atributo y siempre entrecomillar el atributo.
- Dentro de un
<script>/ cadena JS → codificar para JavaScript (escapes Unicode). - Parámetro de URL → codificar para URL.
Los frameworks modernos (React, Angular, Vue) autoescapan por defecto, por lo que el XSS suele aparecer solo donde los desarrolladores recurren a vías de escape como dangerouslySetInnerHTML o v-html.
API DOM seguras
Para el renderizado del lado del cliente, prefiere textContent, setAttribute y createElement frente a innerHTML, document.write y eval. Cuando realmente debas renderizar HTML enriquecido, pásalo por un saneador validado como DOMPurify en lugar de crear el tuyo propio.
Validación de entrada — útil, no suficiente
Valida y rechaza la entrada manifiestamente incorrecta (listas de permitidos, longitud, tipo) en la frontera. Pero la validación por sí sola no puede detener el XSS, porque datos legítimos (un nombre con un <) siguen necesitando codificación al mostrarse.
Content-Security-Policy como respaldo
Una CSP estricta basada en nonce o hash que prohíba el script en línea y eval hace que, aunque una carga útil se cuele, el navegador rechace ejecutarla. Es defensa en profundidad, no un control principal.
Los entrevistadores quieren oír primero «codificación de salida contextual», la comprensión de que la validación no basta, y la CSP enmarcada como respaldo — además de una API segura o un saneador nombrado.
Posibles preguntas de seguimiento
- ¿Por qué la validación de entrada por sí sola es insuficiente para detener el XSS?
- ¿Cómo reduce el impacto del XSS una CSP estricta basada en nonce?
- ¿Cuál es la codificación correcta para datos colocados dentro de una cadena JavaScript?