Tu prueba XSS con alert() se dispara pero la ventana emergente está vacía: ¿qué te dice eso?

Esta trampa castiga observar el resultado en lugar de comprender el mecanismo. Un tester novato ve una caja vacía y concluye «no funcionó, debe de estar saneado». Es lo contrario: la caja vacía es la prueba de que el sitio es vulnerable.

Qué pasó realmente

alert() es una función JavaScript. Para que aparezca una ventana emergente siquiera, el navegador tuvo que analizar tu inyección como código y ejecutarla en el origen de la página. Esa es la definición exacta de cross-site scripting: entrada controlada por el atacante ejecutándose como script en el contexto de la víctima. La aparición del cuadro de diálogo es la señal de éxito. XSS confirmado.

Por qué el mensaje está vacío

El contenido vacío solo te dice que la cadena que pasaste a alert() no sobrevivió intacta. Causas habituales: tus comillas chocaron con el contexto HTML/JS circundante y truncaron el argumento; la aplicación codificó en HTML o eliminó parte de la cadena pero no los caracteres que ejecutan el script; o el valor pasó por una transformación (p. ej. metido en un atributo y luego reflejado) que alteró el texto del payload dejando abierta la ruta de ejecución. El punto de ejecución funciona; los datos que le diste fueron triturados. Es un problema de diseño del payload, no un veredicto de «no vulnerable».

Qué hacer a continuación

Refina el payload para el contexto exacto: corrige el entrecomillado, cambia la entrega (p. ej. alert(document.domain) o literales de plantilla), y luego demuestra impacto real como leer document.cookie o hacer una petición autenticada. La alerta vacía es tu luz verde para escalar, no para parar.

Qué buscan los entrevistadores

El candidato debe reconocer que ejecución = vulnerabilidad, separar el disparo del punto de ejecución del renderizado del payload, y tratar la ventana vacía como un paso de refinamiento. Concluir «saneado, no vulnerable» es la respuesta descalificante.