Izanagi
An access-control vulnerability scanner. It takes an API description and two accounts, builds attack chains and shows the victim's data in the response for every finding. IDOR, BOLA, broken access control - #1 in the OWASP API Top-10 that ordinary scanners miss.
Parses OpenAPI, scores its quality from 0 to 100 and fills the missing responses: sends safe probes to the live API and folds in real data shapes. Traversal goes from GET without params to POST, with writes only on explicit permission.
Classes are baked into the prompt: IDOR in path, query, body and on static files; method probing on 401 and 403; calling admin endpoints with low privileges; mass assignment through privileged fields. Foreign keys aren't invented - it GETs the list first for a real value.
The only module that talks to the target API. It substitutes variables, keeps state between steps and supports filters in extractors, so for IDOR it picks a specific victim instead of guessing a list position.
Every result goes to the model for a verdict: vulnerable, clean or repair. The repair branch rewrites a broken chain a few times. The conclusion is drawn from the actual data in the response, not a guess.
Every finding is checked against the project's history: new or already known, with a first-seen date. What was there before and is gone moves to a “no longer detected” section. Token spend is counted per scan.
$ # bring the stack up in containers $ cp .env.example .env # your model's key and address $ docker compose up -d --build UI http://localhost:3000 API http://localhost:8081 chain-processor http://localhost:8080
Everything builds and runs in containers, no local Go or Node needed. Any model connects: cloud over API or local - the key and address go in .env. VAmPI, a deliberately vulnerable API, comes up as the default target so you can run the whole flow out of the box.
- 01Create a projectTarget, base URL, description, stack. Optionally a custom prompt with roles and domain context.
- 02Set up sign-inA script prints key-value pairs for each account: tokenA, tokenB. Two identities - attacker and victim.
- 03Load OpenAPI and discoveryUpload the spec and run discovery from the SPEC tab. It enriches the description with real responses and lifts chain quality.
- 04Start a scanPick vulnerability classes, the number of chains, optionally deep analysis with repair. The engine takes it from there.
- 05Review findingsTabs for chains, vulnerabilities and the log. Each vulnerability gets a “new” or “known” badge and proof: the victim's data in the response.
GET /users/{id} doesn't check ownership (CVE-2023-0298): the response holds another account's email and data.
DELETE /snapshots/{key} doesn't check the organization (CVE-2024-1313): the victim's control GET returns 404.
GET /api/records/1 returns another patient's medical record (training testbed).
Admin functions and another car's location on a training marketplace.
Another user's book and profile on a training API.
On real products - an exact reproduction of known CVEs plus findings on our own platform. Training testbeds are stuffed with vulnerabilities on purpose, so there are naturally more findings there.
A finding opens a ticket on its own: with a link to the chain, severity and proof in the response. Status syncs back.
Export findings to the standard SARIF format so GitHub Code Scanning, GitLab and other systems pick them up.
A Helm chart and manifests: the whole stack deploys into the customer's cluster with one command, no manual container builds.
A per-scan summary in one place: findings by severity, trends between runs, token spend and cache share.
Chain generation, verdict and repair on a tool-use agent, prompt caching, any model over API. Done and in production.