XSS: Cross-Site Scripting explicado en términos simples
XSS (cross-site scripting) es cuando una persona externa logra ejecutar su código en las páginas de tu sitio, dentro del navegador del visitante. La vulnerabilidad no está en el servidor, sino en cómo el sitio muestra los datos que llegan de fuera: de la dirección, un formulario, un comentario o un perfil.
Una analogía para el dueño del sitio
Imagina un tablero de avisos a la entrada de una tienda. Si alguien trae una nota que dice: "entrega las llaves de la caja registradora al portador", y la cuelgas sin leerla, el empleado seguirá las instrucciones de otra persona como si fueran tuyas. El XSS funciona igual: el sitio inserta texto ajeno en la página como si fuera propio, y el navegador ejecuta todo lo que hay ahí, confiando plenamente en tu dominio.
Tipos de XSS
| Tipo | Dónde vive | A quién afecta |
|---|---|---|
| Reflejado | El valor de la dirección o del formulario se devuelve directamente en la respuesta HTML | A quien hizo clic en el enlace manipulado |
| Almacenado | El texto ajeno se guarda en la base de datos: comentario, reseña, nombre de perfil | A todos los que abren esta página |
| Basado en DOM | Los propios scripts del sitio insertan en el marcado datos tomados de la dirección | A los visitantes, y en la respuesta del servidor no quedan rastros |
Qué riesgos implica
- Robo de sesión. Un script ajeno lee las cookies e inicia sesión en la cuenta o en el panel de administración en nombre del usuario.
- Spam y enlaces ocultos. El sitio empieza a promocionar temas ajenos y pierde la confianza de los buscadores.
- Etiqueta en el navegador y en los resultados de búsqueda. Si se inyectó código malicioso a través de la vulnerabilidad, el dominio acaba en las bases de datos de sitios no seguros, el visitante ve la advertencia "este sitio puede dañarte" y las páginas salen del índice.
Cómo se ve en el informe de Security Shield
El escáner inserta un marcador inofensivo en los parámetros de la página y comprueba si vuelve en el HTML sin escapar. Si vuelve, aparece el hallazgo "Indicio de XSS reflejado": severidad media, clase CWE-79, categoría OWASP A03:2021. La nota "requiere verificación" significa que el servicio detecta la superficie de ataque, pero no la explota.
Las sondas activas solo se realizan en los modos de pago y en dominios verificados: la revisión rápida gratuita no las ejecuta. Qué más se revisa se explica en el artículo sobre Security Shield.
Abre la dirección y el parámetro de la línea "Dónde se encontró" y pide al desarrollador que revise si este valor se escapa al mostrarse. Reflejar valores sin procesar en el HTML es señal de que aquí no hay ningún filtro.
Cómo solucionarlo
- Escapa la salida. Los datos del usuario pasan por una codificación contextual antes de insertarse en el HTML: <, >, las comillas y los ampersands se convierten en secuencias seguras. En los motores de plantillas, esto es una sola configuración.
- Revisa lo que entra. Si el parámetro es un número, acepta solo números. Para textos con marcado, usa una biblioteca de limpieza de HTML comprobada.
- Activa CSP: incluso si hay un error en la plantilla, evitará que se ejecute un script ajeno. Cómo empezar se describe en el artículo sobre encabezados de seguridad.
- Protege las cookies con las banderas HttpOnly y Secure, para que la sesión no se pueda leer desde JavaScript.
- Actualiza el CMS, el tema y los plugins. La mayoría de los XSS en sitios típicos provienen de extensiones de terceros.
Cómo evitar que vuelva a ocurrir
La regla es simple: cada campo nuevo que ve el visitante pasa por la misma salida segura que los demás. Mantén CSP activado y repite los escaneos después de cada lanzamiento y de instalar plugins. También es útil una auditoría SEO: un aumento repentino en la cantidad de enlaces externos suele ser la primera señal de una inyección.