El XSS es cuando el texto escrito en un formulario se ejecuta como un script en la pantalla de otra persona. 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 el fallo más grave en el lado del servidor, el XSS es el más grave en el lado del cliente (usuario).
Defensa: escapa 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 se cuele un XSS, el daño es menor.
La visión de este sitio: la mejor defensa es no desactivar tú mismo las funciones de seguridad
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, no por tu propio manejo de cadenas. «Desactivar la seguridad por comodidad» es el mayor riesgo.
En qué se diferencia el XSS de los ataques con los que se confunde
El XSS se confunde a menudo con el CSRF, que tiene un nombre parecido, y con la inyección SQL, que también es un caso de entrada tratada como instrucciones. La diferencia está en qué se ejecuta y dónde.
| Ataque | Qué ocurre y dónde | Defensa principal |
|---|---|---|
| XSS | El script del atacante se ejecuta en el navegador del usuario como parte de la página real | Escape en la salida, CSP |
| CSRF | Se usa la sesión iniciada del usuario para enviar una petición que no pretendía. No hace falta que se ejecute ningún script | Tokens CSRF, cookies SameSite |
| Inyección SQL | La entrada se interpreta en el servidor como parte de una sentencia SQL | Marcadores de posición (placeholders) |
| Clickjacking | La página real se superpone de forma invisible para que el usuario haga clic en ella sin saberlo | CSP frame-ancestors |
Ten en cuenta que el XSS también anula las defensas contra el CSRF. Una vez que un script se ejecuta dentro de la página, también puede leer el token CSRF de esa página (la guía de OWASP sobre CSRF da la misma advertencia).
Un caso real: XSS en una pantalla que abre el personal
En 2026, Instructure, la empresa detrás del sistema de gestión del aprendizaje Canvas, dijo que una intrusión empezó con un XSS. Según la empresa, el atacante usó una cuenta gratuita para enviar un ticket de soporte con código malicioso, y cuando un agente de soporte lo abrió, se aprovechó un fallo XSS para obtener privilegios elevados dentro de Canvas (→ la brecha de datos de Canvas (Instructure)).
La lección es que el XSS no es solo un problema de las páginas públicas. Las pantallas de soporte, contacto y administración que muestran a tu propio personal texto enviado desde fuera conllevan más riesgo, porque las cuentas que las abren tienen más poder.
El XSS sigue estando entre las debilidades más comunes. En el «CWE Top 25» de MITRE (las 25 debilidades de software más peligrosas), publicado en diciembre de 2025, el XSS (CWE-79) quedó en primer lugar. En septiembre de 2024, las agencias estadounidenses CISA y FBI también emitieron una alerta pidiendo a los fabricantes de software que eliminaran el XSS de sus productos.
Cómo comprobar tu propio sitio
No necesitas probar cadenas de ataque. Empieza por estas cuatro comprobaciones.
Busca los lugares que insertan HTML en bruto
Busca en tu código dangerouslySetInnerHTML, v-html, innerHTML y document.write, y comprueba si algún valor proporcionado por el usuario puede llegar a ellos. Si puede, muéstralo como texto o pásalo por un saneador probado.
Comprueba si se envía la CSP
Usa la comprobación de cabeceras de seguridad para ver si Content-Security-Policy está presente y qué permite. Permitir 'unsafe-inline' la debilita mucho frente al XSS. Para escribir una nueva, redáctala con el generador de CSP y ejecútala primero en modo Report-Only (que solo informa de las infracciones).
Comprueba los atributos de tu cookie de sesión
En las herramientas para desarrolladores del navegador (Aplicación → Cookies), confirma que la cookie de sesión tiene HttpOnly y Secure. La auditoría del sitio también comprueba los atributos de las cookies.
Incluye las pantallas de administración y soporte
Comprueba que las pantallas internas que muestran texto llegado de fuera (cuerpos de tickets, nombres de archivo, nombres visibles) se escapan con el mismo nivel que las páginas públicas.
Fuentes (primarias)
- OWASP, «Cross Site Scripting Prevention Cheat Sheet» (en inglés) — cheatsheetseries.owasp.org (escape según el contexto de salida, valores por defecto seguros de los frameworks)
- MITRE, «2025 CWE Top 25 Most Dangerous Software Weaknesses» (diciembre de 2025, en inglés) — cwe.mitre.org (CWE-79 en primer lugar)
- CISA y FBI, «Secure by Design Alert: Eliminating Cross-Site Scripting Vulnerabilities» (17 de septiembre de 2024, en inglés) — cisa.gov
- OWASP, «Cross-Site Request Forgery Prevention Cheat Sheet» (en inglés) — cheatsheetseries.owasp.org (el XSS puede saltarse las defensas contra el CSRF)
- IPA, «How to Secure Your Web Site» — ipa.go.jp (en japonés)
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
- Defensa en profundidad: las cabeceras de seguridad no son una lista para acumular (CSP limita lo que puede hacer un XSS)