What it actually is
awp is a hub-and-spoke system driven by the OWASP WSTG. An orchestrator fingerprints the app, reasons out a test plan, and dispatches category specialists —> recon, config, auth, authorization, session, input/injection, business logic, client-side, and API, in parallel where they’re independent. Everything routes through Burp Suite Pro over MCP so session state and evidence stay centralized.
The part I care about most is the finding-validator: a deliberately adversarial gate that independently reproduces every candidate, builds a minimal PoC, and rejects anything it can’t prove. The whole thing is tuned for one metric, validated, exploitable true positives. Scanner noise is a lead, never a finding. False positives are treated as failures.
First run: the numbers
An authorized engagement against a modern web application with an authenticated user surface and a JSON API.
| High | Medium | Low | Info |
|---|---|---|---|
| 2 | 2 | 3 | 2 |
| Class | What it was |
|---|---|
| High | Broken function-level authorization. A standard, low-privileged user could create top-level objects the UI explicitly forbids, the create action simply wasn’t authorized server-side. It was systemic, reaching the create path on several object types. |
| High | Broken object-level read authorization (IDOR). A user could read records they weren’t authorized to, straight from the API, even though the app itself computed can_read: false and then served the full object anyway. |
| Med | Object-level mass assignment. Server-controlled fields (like ownership) were bound from client input on create, letting records be attributed to other, including privileged, users. |
| Med | Stored HTML injection. User content was stored and rendered unsanitized. The only thing preventing full stored XSS was a strict Content-Security-Policy, a single point of failure one config change away from High. |
| Low | Broken self-service password reset, an object-ID enumeration oracle, and publicly-served production source maps. |
| Info | A cross-user cache-token weakness and a permissive CSP directive. |
The recurring theme writes itself: the UI said no; the server didn’t enforce it. Hidden buttons and disabled controls aren’t authorization, awp treats the HTTP API as the real attack surface, so the functions the UI never offers you still get tested.
What actually impressed me
Two things stood out on a real run rather than a lab:
- The validator earned its keep. One candidate looked like a potential critical privilege escalation. The validator re-tested it properly, proving the request body was actually delivered first, and the “critical” collapsed into a clean true negative. That’s exactly the false positive you don’t want to hand a client.
- It degrades instead of giving up. When an automated step got blocked mid-run, the plugin packaged the exact command for me to run locally and fed the output back through validation, rather than reporting an unverified finding.
What’s next
I’ve already added an LLM / AI-chatbot specialist mapped to the OWASP Top 10 for LLM Apps, prompt injection, insecure output handling (where the model’s output becomes XSS/SQLi/SSRF downstream), and excessive agency (BOLA/BFLA through a chat interface).
awp is open source: github.com/xcoy0te/Claude-AutonomousWebPentest. Authorized testing only — every run reads a scope file first and refuses anything outside it.