Una aplicación es vulnerable a XSS cuando muestra datos que controla un usuario (un comentario, un parámetro de la URL, un nombre de perfil) sin escaparlos correctamente. El código inyectado corre con los permisos del sitio: puede leer lo que ve la víctima, hacer acciones en su nombre o mostrarle contenido falso. Hay tres variantes clásicas: reflejado (viaja en la URL), almacenado (queda guardado, por ejemplo en un mensaje) y basado en DOM (lo arma el propio JavaScript de la página).
🧪Ejemplo
Un foro muestra el título de un tema dentro de un atributo HTML sin escapar las comillas. Alguien publica un título como Código: text
Ayuda" onmouseover="alert(1)
y el navegador interpreta lo que sigue a la comilla como un atributo nuevo con código.
🛡Cómo protegerse
Escapar toda salida según el contexto: texto HTML, atributos, URLs, CSS y JavaScript necesitan escapes distintos.
Usar plantillas o frameworks que escapen por defecto y evitar innerHTML con datos del usuario.
Agregar una Content-Security-Policy (CSP) que bloquee scripts inline.
Marcar las cookies de sesión como HttpOnly para que JavaScript no pueda leerlas.
⚠Para tener en cuenta
Probar XSS solo está permitido en sistemas propios, laboratorios o programas de bug bounty que lo autoricen.
Redactado con el asistente Underc0de IA. Actualizado el 07/11/2026. ¿Ves un error o querés sumar algo? Contanos en el foro.
