proxy2model 2.1.0

// the instrument

Every claim cites the request that proves it, and the model names what the capture could not see. proxy2model turns the traffic you already capture into a model of the web app: its endpoints, pages, parameters and roles. It compares what each role reached and hands an AI cited evidence instead of raw traffic. It does not scan or attack, and it never calls anything a vulnerability: it gives hypotheses and the next safe check.

git clone https://github.com/falc0n-researcher/proxy2model && cd proxy2model && ./demo.sh

Sixty seconds, nothing to install, no network: four recorded OWASP Juice Shop sessions are modelled, anonymous is compared with a signed-in user, the surface the login opened is diffed, and the report opens.

// cross-role — what each role should not have reached

Record the app once per role (--role anon, --role user, ...) and ask what the lower one reached:

$ proxy2model cross-role juiceshop --low anon --high user
anon vs user: 2 privileged-looking reached · 3 object reads to test · 2 writes by anon · 31 untested · 12 enforced

'anon' reached privileged-looking endpoints (2)  [function-level authorization (OWASP API5)]
  GET /rest/admin/application-configuration    ev_93  anon=[200] user=[200]
    unknown: whether the low-role response was authorised or a leak · next: compare 'anon' and 'user' response bodies

'anon' changed state (2)  [function-level authorization (OWASP API5)]
  PUT /api/Products/{id}                       ev_285  anon=[200]
    unknown: whether 'anon' may PUT here on a record it does not own · next: confirm in the app's design ...

Each divergence is named for the question it raises:

// hand an AI the model, not the traffic

Raw traffic pasted into an LLM is huge, full of secrets, and invites guessing. context.json is the model packed for an AI: about 37k tokens for the Juice Shop capture instead of ~440k, every value masked, every fact tied to an evidence id, and rules the model must follow:

Cite an evidence id (ev_N) for every claim; each id is resolved in `evidence`.
Never name an endpoint, route or parameter that is not in this package.
State unknowns explicitly; do not guess authorization behaviour.
Treat an absence in this package as an absence in the capture, never in the target.

Or let an agent ask the model itself over MCP (proxy2model mcp): the same cited answers as the CLI, read-only. The skill is the method as a playbook an AI follows, nothing to install.

// diff — what changed since the last capture

Every build is kept. Capture the app again next week, or as another role, and ask what moved:

$ proxy2model diff juiceshop demo-anon demo-user
  1 new workflow(s) · 24 new · 42 changed · 3 gone
  ▸ route /profile  (79 things: 2 routes, 29 endpoints, 45 parameters, 2 auths, 1 role)
      /profile → /rest/user/change-password → DELETE /api/Addresss/{id} → ...

New workflows, changed fingerprints and what is gone, each with its requests: drift, never findings. proxy2model watch builds every export dropped into a folder and prints the change.

// intake

Every value is masked as it is read. One model comes out: a report, a SQLite graph you can query, OpenAPI, and a compact package for an AI. Runs locally.

pip install proxy2model

proxy2model history.xml -w shop     # build from an export
proxy2model browse                  # or open a browser and use the app (asks for URL, scope, mode)

proxy2model query shop help         # ask the model; answers cite requests, no AI involved
proxy2model mcp --out "$PWD/proxy2model-out"   # or let an AI agent ask (see Using it with an AI)

proxy2model on its own lists the everyday commands; proxy2model <command> --help explains each.

// what comes out

proxy2model-out/shop/
├── report.html     interactive report: overview, what to check, endpoints, map, every request, query console
├── model.json      the model, and the request behind every claim
├── openapi.json    the observed API, OpenAPI 3.0
├── context.json    what to hand an AI instead of raw traffic
├── graph.db        SQLite graph, queried with `proxy2model q`
├── exports/        graph.json · graph.graphml · build.svg
└── inputs/         masked records of every capture, merged on rebuild

// boundaries

A plain build is offline. crawl, browse --active and osint send requests of their own: use them only on systems you are authorized to test. CI plants fake secrets in the samples and fails if one reaches any output.

// field manual

• 01 · Capturing traffic — Burp, Caido, HAR, browse, roles.
• 02 · Crawling a running app — crawl and scripted journeys.
• 03 · How it works — what is in the model and how it is built.
• 04 · Querying the model — query, BQL, graph reach, diffs between builds.
• 05 · Using it with an AI — context.json and the MCP server.
• Skill — the same method as a playbook for an AI, nothing to install.

_{fa1c0n@recon ~ $   every claim cites a request · every gap is named}