Primero el contexto: la parte de las pruebas XSS que aún se apresura
La elección del payload importa menos que el contexto de inyección: HTML, atributos, URLs, scripts y sinks DOM fallan de formas distintas.
Muchas pruebas XSS malas empiezan con una lista de payloads.
Eso parece útil hasta que la aplicación refleja la entrada dentro de un atributo con comillas, dentro de una cadena JavaScript o después de que un sanitizer haya reordenado el marcado. Entonces la lista se vuelve ruido.
Empieza por el contexto.
El mismo payload no es la misma prueba
"><svg onload=alert(1)>
Ese texto significa algo en un atributo HTML, otra cosa en una respuesta JSON y casi nada si la aplicación usa textContent. Un payload es una hipótesis sobre cómo el navegador parseará esos caracteres después de que la aplicación, el framework y los filtros hayan intervenido.
Los atributos tienen bordes molestos
¿El atributo está entre comillas? ¿Simples o dobles? ¿El framework escapa comillas pero no backticks? ¿Es href, src, style, data-* o un manejador de evento? Cada caso requiere una estrategia distinta.
DOM XSS necesita flujo de datos
La fuente puede ser location.hash, postMessage, query params o local storage. Más tarde, otro componente escribe el valor en innerHTML o insertAdjacentHTML. Seguir esa ruta produce mejores reportes que lanzar cadenas al azar.