Glosario
Qué es el XSS (Cross-Site Scripting): código ejecutándose en el navegador de otra persona
El XSS (Cross-Site Scripting) hace que el script de un atacante se ejecute en el navegador de otro usuario, llevando al robo de sesión y la alteración de la página. Los tipos (almacenado, reflejado, DOM) y la defensa real: escape en la salida y CSP.
«El texto que escribí en un formulario se ejecuta como un script en la pantalla de otra persona»: eso es el XSS. Aquí tienes cómo funciona y cómo prevenirlo de forma fiable (sin pasos de ataque).
Los tres tipos
El XSS se divide según «cómo llega la cadena maliciosa a la ejecución».
| Tipo | Cómo se planta |
|---|---|
| Almacenado | Guardado en una publicación/perfil y se ejecuta para todo el que lo ve (el más peligroso) |
| Reflejado | Un parámetro de URL se refleja directamente en la página; se ejecuta para quien haga clic en el enlace |
| Basado en DOM | Sin ida y vuelta al servidor: el JS del lado del cliente maneja la entrada de forma insegura |
Por qué es peligroso (cómo funciona)
El navegador ejecuta cualquier <script> de la página como «código legítimo». Si la cadena de un atacante aterriza como HTML en la página, el navegador no puede distinguirla del código real.
El daño es «todo lo que esa página pueda hacer». Si la RCE es lo peor en el lado del servidor, el XSS es lo peor en el lado del cliente (usuario).
Defensa: la solución real es «escapar en la salida»
El XSS se previene en la salida, no en la entrada. En el momento en que renderizas un valor, conviértelo para que no pueda interpretarse como HTML.
Escapa en la salida (lo más importante)
Al renderizar valores proporcionados por el usuario, convierte < > & " ' en entidades HTML, usando el método correcto según el contexto (cuerpo HTML, atributo, JS, URL).
No desactives el autoescape de tu framework
React/Vue/plantillas autoescapan por defecto. Solo evita la inyección de HTML en bruto (dangerouslySetInnerHTML, v-html) y prevendrás la mayoría del XSS.
Defensa en profundidad con CSP
La Content-Security-Policy permite al navegador bloquear scripts que no autorizaste, limitando el daño aunque algo se cuele.
Protege las cookies
Marca las cookies de sesión con HttpOnly para que JS no pueda leerlas. Aunque las roben, el radio de impacto es menor.
La visión de este sitio: la mejor defensa es no abrir tú mismo el agujero
Los frameworks modernos son seguros por defecto. La mayoría del XSS aparece en el momento en que un desarrollador desactiva deliberadamente el autoescape para «inyectar HTML en bruto». Si realmente debes permitir HTML, pásalo por un saneador probado en combate, no por tu propio manejo de cadenas. «Desactivar la seguridad por comodidad» es el mayor riesgo.
Sigue leyendo
- Glosario: Qué es CSRF · Qué es RCE · Qué es un JWT (un token que a menudo se roba mediante XSS)
- Fundamentos: Fundamentos de seguridad
FAQ
Q¿Qué ocurre con el XSS?
El script de un atacante se ejecuta en el navegador de la víctima como parte de la página real. Eso puede significar robo de sesión (inicio de sesión suplantado), lectura de lo que se introduce, desfiguración de la página o ejecución automática de otras acciones.
Q¿Cuál es la mejor defensa contra el XSS?
El escape en la salida: cuando renderizas valores proporcionados por el usuario, conviértelos para que no se interpreten como HTML. Las plantillas de React/Vue lo hacen por defecto, así que la mayor victoria es no desactivar ese autoescape (evita dangerouslySetInnerHTML, etc.). Añade CSP como defensa en profundidad.
Q¿Basta con sanear en la entrada?
Normalmente no. La solución real es el escape según el contexto de salida (cuerpo HTML, atributo, JS, URL). Los filtros de entrada por sí solos filtran por desajustes de contexto. Solo cuando debas permitir HTML, pásalo por un saneador de confianza.