Por qué usar NotHoly para seguridad de web y API

Probar web y API es leer: una petición, una respuesta, un bundle de JavaScript, una spec OpenAPI, y luego escribir la siguiente petición que prueba el bug. Un modelo genérico titubea en cuanto le pides la cadena de inyección o el bypass de auth, y un scanner encuentra lo superficial y para. NotHoly lee lo que pegas, escribe el test y deja el envío a tu proxy. Mantienes Burp, Caido, ZAP o tus scripts; el modelo es el lector y el escritor en el bucle. El caso de uso de pentest tiene la metodología; esto es sobre por qué el modelo encaja en trabajo de web y API.

#Pega la petición, la respuesta o la spec

Dale al modelo el HTTP crudo, una respuesta que parece mal, un trozo de un bundle o un documento OpenAPI, y nombra lo que falta: una referencia de objeto sin control de dueño, un endpoint que confía en un rol del lado del cliente, un parámetro que llega a una query sin escapar, un token que no se valida. Explica por qué, y marca la petición a enviar después. Pega una respuesta con un encabezado raro o una fuga de error, y te dice qué revela y cómo presionar. Como el modelo no rechaza la tarea, un recorrido de IDOR, una sonda de SQL injection o un test de confusión de JWT se escribe como cualquier otro código, mientras el objetivo esté en tu alcance. El reasoning sigue, así que un flujo de auth de varios pasos se resuelve antes de escribir el payload.

#Payloads y controles para tu proxy

Pide el artefacto que usa tu herramienta, y el modelo lo escribe: una Bambda o un BCheck de Burp, un workflow de Caido, un tamper script de sqlmap, la lógica para una corrida de ffuf, un script pequeño de requests. La base de conocimiento es parte del modelo, así que trae OWASP WSTG, el API Security Top 10, la Cheat Sheet Series y la documentación de herramienta de Caido y Burp con una fuente y licencia en cada pasaje. Una versión de framework que encuentras va a un lookup de CVE con CVSS, EPSS y KEV, y una dependencia va a una consulta de advisory, ninguno de los dos cuesta tokens. El resultado es un payload con un motivo y una referencia, no una adivinanza. También mantienes el flujo entero en una conversación, desde la primera respuesta rara hasta el test terminado, así que el contexto que explica por qué un payload funciona no se pierde entre pestañas.

cat request.http | notholy "what auth checks is this endpoint missing, and write a Caido test for the IDOR"

#El tráfico sigue siendo tuyo

Los servidores de NotHoly nunca escanean, sondean ni envían un payload a un objetivo. Las peticiones que prueban la aplicación vienen de tu proxy y tus scripts, en tu máquina, desde tu dirección. Cuando lo diriges desde la terminal, notholy engage registra el alcance que puedes tocar y revisa cada comando contra él, y el lector de páginas abre solo páginas públicas por una salida que rechaza direcciones privadas e internas. Los resultados de herramienta que devuelves se tratan como dato, así que un payload reflejado en una respuesta no se vuelve instrucción al modelo. El modelo lee; tus herramientas envían.

notholy kb "jwt none algorithm" --json

#Dónde no encaja

No es un scanner ni un sustituto de DAST o SAST. No va a rastrear la aplicación ni a disparar las peticiones, y un payload sugerido puede ser una pista falsa, así que confírmalo contra el objetivo en ejecución antes de que entre en un hallazgo. El lector de páginas abre solo páginas públicas, no un endpoint autenticado ni un host interno. El modelo puede equivocarse sobre un control o inventar un parámetro, así que lee la petición que escribe antes de enviarla. Una lectura limpia no es prueba de que la aplicación esté segura, y la cuenta necesita un correo.

Deja que tu proxy mande el tráfico y el modelo lea las respuestas. Instala la CLI, pon un saldo pequeño en precios, y pega la primera petición.