Metodología para IDOR, XSS, SSRF y auth rota con un modelo de IA como lector y segunda opinión, más cómo confirmar un finding y evitar falsos positivos.
Con una lista confirmada de endpoints de leer el JavaScript, puedes empezar a probar bugs de verdad. Este post cubre cuatro clases que un principiante encuentra temprano: IDOR, cross-site scripting, server-side request forgery y autenticación rota. El modelo te ayuda a leer responses y decidir la siguiente prueba. Tú corres cada request y confirmas cada finding a mano. Mantén toda prueba en los hosts que el programa lista, y usa una copia local de la app para cualquier cosa ruidosa.
El modelo es un segundo par de ojos sobre una response. Pega un request y su response y pregunta qué parece hacer el servidor con tu entrada, qué devolvería en cambio una app segura, y qué único cambio te diría más. Es rápido en esto y a veces estará seguro y equivocado, así que cada respuesta es una hipótesis que pruebas, no una conclusión que reportas. La OWASP Web Security Testing Guide tiene el procedimiento completo para cada clase de abajo.
| Clase | La pregunta que haces | Cómo confirmas |
|---|---|---|
| IDOR | ¿Puedo llegar al objeto de otro usuario? | Dos cuentas, cambia el id, compara responses |
| XSS | ¿Mi entrada corre como código? | La entrada reflejada ejecuta en un navegador real |
| SSRF | ¿El servidor traerá una URL que yo elijo? | Un host que controlas registra el request del servidor |
| Auth rota | ¿Puedo actuar sin la sesión correcta? | Un request sin token o con el rol equivocado funciona |
Insecure direct object reference es el bug más amable para un principiante. Encuentra un request con un identificador dentro, como /api/orders/1051, y cambia el número. Si recibes de vuelta el pedido de otro usuario, la app no está chequeando quién es el dueño. La forma limpia de probarlo es con dos cuentas que controlas: trae tu propio objeto, luego prueba el identificador de la otra cuenta desde tu sesión, y compara. El modelo te ayuda a ver qué campos son identificadores y qué responses difieren de una forma que importa.
El cross-site scripting pasa cuando la entrada que envías vuelve a una página sin ser codificada, así que el navegador la corre como script. Tu trabajo al probar es hallar un lugar donde la entrada se refleje en la response y chequear si se queda como dato o se vuelve código. Un string marcador inofensivo te dice si tu entrada se codifica, y cómo. Cross-site scripting explicado tiene el detalle. El modelo sirve para leer cómo se refleja un valor y dónde falta la codificación, pero solo un navegador real prueba la ejecución, así que confirma ahí.
El server-side request forgery pasa cuando la app toma una URL de ti y el servidor la trae. Busca funciones que jalan un recurso remoto: una imagen por URL, un webhook, un preview de enlace. Para probar con cuidado, apunta la función a un host que controlas y observa tus propios logs por el request del servidor. Si el servidor sale, confirmaste el comportamiento, y el impacto depende de a qué puede llegar la red del servidor. Describe solo lo que probaste, y no salgas a cazar servicios internos más allá de lo que el programa permite.
Esta clase cubre requests que deberían necesitar una sesión válida o un rol específico y no lo hacen. Toma un request autenticado, quita el token o cambia a una cuenta de menor privilegio, y mira si todavía funciona. Los bugs de control de acceso son comunes, a menudo de alto impacto y fáciles de probar con dos cuentas. El modelo puede ayudarte a enumerar qué acciones reintentar sin sesión, desde la lista de endpoints que armaste antes.
La mayor parte del tiempo perdido en el primer mes de un principiante se va en falsos positivos que el modelo alentó. Tres hábitos lo evitan. Reproduce el bug desde un estado limpio para saber que es real y no una rareza de caché. Cambia una variable a la vez para saber qué causó el resultado. Guarda el request y la response exactos que lo prueban, porque eso es lo que el reporte necesita y lo que el triager volverá a correr. Si no lo reproduces cuando quieres, todavía no es un finding.
Las APIs merecen su propio método. Testing de APIs con IA cubre OpenAPI y GraphQL. El OWASP Top 10 y la PortSwigger Web Security Academy son las referencias para trabajar en cada clase.
Seguridad web y de APIs
El JavaScript del front-end lista la API que habla una app. Usa un modelo de IA para leer bundles y sacar endpoints y parámetros, que luego confirmas tú.
Seguridad web y de APIs
Las APIs exponen su forma con specs OpenAPI e introspection de GraphQL. Usa un modelo de IA para leer el schema y planear pruebas de autorización.
Seguridad web y de APIs
Pega la petición, la respuesta o la spec OpenAPI. El modelo nombra el control que falta y escribe el test para tu proxy. Tu proxy manda el tráfico.
