Why use NotHoly for web and API security testing

Web and API testing is reading: a request, a response, a JavaScript bundle, an OpenAPI spec, then writing the next request that proves the bug. A general model hedges the moment you ask for the injection string or the auth bypass, and a scanner finds the shallow issues and stops. NotHoly reads what you paste, writes the test, and leaves the sending to your proxy. You keep Burp, Caido, ZAP or your own scripts; the model is the reader and the writer in the loop. The pentest use case has the methodology; this is about why the model fits web and API work.

#Paste the request, the response or the spec

Give the model the raw HTTP, a response that looks wrong, a chunk of a bundle or an OpenAPI document, and it names what is missing: an object reference with no ownership check, an endpoint that trusts a client-side role, a parameter that reaches a query unescaped, a token that is not validated. It explains why, and it marks the request to send next. Paste a response with an odd header or an error leak, and it tells you what that reveals and how to push on it. Because the model does not refuse the task, an IDOR walk, a SQL injection probe or a JWT confusion test is written like any other code, as long as the target is in your scope. Reasoning carries through, so a multi-step auth flow is worked out before the payload is written.

#Payloads and checks for your proxy

Ask for the artifact your tooling uses, and the model writes it: a Burp Bambda or a BCheck, a Caido workflow, a sqlmap tamper script, the logic for an ffuf run, a small requests script. The knowledge base is part of the model, so it pulls OWASP WSTG, the API Security Top 10, the Cheat Sheet Series and tool documentation for Caido and Burp with a source and licence on each passage. A framework version you find goes to a CVE lookup with CVSS, EPSS and KEV, and a dependency goes to an advisory query, neither of which costs tokens. The result is a payload with a reason and a reference, not a guess. You can also keep the whole flow in one conversation, from the first odd response to the finished test, so the context that explains why a payload works does not get lost between tabs.

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

#The traffic stays yours

NotHoly's servers never scan, probe or send a payload to a target. The requests that test the app come from your proxy and your scripts, on your machine, from your address. When you drive it from the terminal, notholy engage records the scope you are allowed to touch and checks each command against it, and the page reader opens only public pages through an egress that refuses private and internal addresses. Tool results you feed back are treated as data, so a reflected payload in a response does not become an instruction to the model. The model reads; your tools send.

notholy kb "jwt none algorithm" --json

#Where it does not fit

It is not a scanner and not a replacement for DAST or SAST. It will not crawl the app or fire the requests, and a suggested payload can be a false lead, so confirm it against the running target before it goes in a finding. The page reader opens public pages only, not an authenticated endpoint or an internal host. The model can be wrong about a check or invent a parameter, so read the request it writes before you send it. A clean read is not proof the app is safe, and the account needs an e-mail.

Let your proxy send the traffic and the model read the responses. Install the CLI, add a small balance on pricing, and paste the first request.