El Cross-Site Scripting (XSS) ocurre cuando una aplicación incrusta datos del usuario en una página sin sanitizarlos, permitiendo que se ejecute código (normalmente JavaScript) en el navegador de quien la visita. La víctima no es el servidor, sino otros usuarios.
Los tres tipos
| Tipo | Dónde vive el código | Cómo se dispara |
|---|---|---|
| Almacenado (persistente) | Guardado en el servidor (comentario, perfil) | Con cada usuario que carga la página. El más grave |
| Reflejado | Viaja en la petición (parámetro de URL) | La víctima abre un enlace preparado |
| Basado en DOM | En el propio JavaScript del cliente | El JS de la página usa datos no confiables |
Qué puede lograr un atacante
- Robar cookies de sesión y suplantar a la víctima.
- Realizar acciones en su nombre (cambiar el correo, transferir, publicar).
- Capturar pulsaciones de teclado o credenciales de un formulario falso.
- Redirigir a sitios de phishing.
<!-- Ejemplo simple de payload de prueba -->
<script>alert(document.domain)</script>
Las defensas
Escapar la salida (output encoding). Antes de mostrar datos del usuario, convertir caracteres especiales (
<,>,",',&) en sus entidades para que se vean como texto y no se ejecuten.
Complementos:
- Content Security Policy (CSP): una cabecera que limita desde dónde se cargan y ejecutan scripts.
- Sanitización con librerías probadas (por ejemplo, DOMPurify) cuando se debe permitir HTML.
- Marcar las cookies de sesión como HttpOnly, para que el JavaScript no pueda leerlas.
- Frameworks modernos (React, Angular) escapan por defecto; el riesgo aparece al forzar HTML crudo.
XSS abusa de datos que se muestran sin limpiar. La siguiente falla no inyecta nada: abusa de que la aplicación no comprueba bien los permisos. Es el control de acceso roto / IDOR, el próximo tema.