vulnapi is an open-source DAST written in Go that scans your own APIs for common vulnerabilities, missing security headers, and authentication weaknesses during authorized security testing.
| Tool | cerberauth/vulnapi — open-source API security DAST scanner written in Go, MIT licensed |
| Category | Dynamic application security testing (DAST) for REST and GraphQL APIs |
| Primary Use | Scanning APIs you own or are authorized to test, via a curl-like CLI or OpenAPI contracts, to find OWASP API weaknesses before deployment |
| Safe Use | Use only in authorized assessments, CI/CD pipelines, and lab environments against APIs you control; the README's disclaimer explicitly prohibits attacking systems without proper authorization |
| Telemetry Note | The tool phones home anonymous usage statistics (scan counts, vulnerability counts and severities) unless --sqa-opt-out is passed; scans themselves generate request logs visible to defenders and leave no persistence |
vulnapi from cerberauth positions itself as an open-source dynamic application security testing (DAST) tool aimed squarely at API surfaces, a niche where commercial scanners dominate and open-source alternatives tend to be either unmaintained or narrowly scoped. Written in Go, released under the MIT license, and sitting at roughly 291 stars with active CI workflows on main, it targets the practitioner who wants a repeatable, scriptable first-pass audit of REST and GraphQL endpoints during development or an authorized engagement. The framing throughout the README is defensive: detect and mitigate weaknesses in your own APIs before an attacker does. That positioning matters for how you should deploy it — as a pre-production gate or assessment aid, not a point-and-shoot weapon.
The architecture is split into three verbs, and the CLI help output in the README makes this immediately legible: discover, scan, and serve, plus an interesting jwt subcommand for generating test tokens. The discover command is effectively reconnaissance-lite against a target you control: vulnapi discover api [API_URL] probes for exposed OpenAPI documents at conventional locations, GraphQL endpoints, .well-known paths such as jwks.json, and leaked files like .env.dev. The sample output in the README shows it also fingerprinting the stack — identifying Flask:2.2.3 and Python:3.7.17 from response characteristics — which suggests it embeds projectdiscovery/wappalyzergo for technology detection, a dependency the authors credit explicitly.
Fingerprinting before scanning is a sound design choice because it lets the scanner contextualize findings, and the README's example tables demonstrate this pairing of discovery output with vulnerability output. Seeing an exposed .env.dev file surfaced in the same table as the framework version immediately tells an operator two things: the deployment hygiene is poor and the attack surface needs mapping before deeper tests. The well-known path checks for jwks.json are a natural precursor to JWT-focused testing, hinting that the tool's authors think in terms of authentication attack chains rather than isolated header checks.
Scanning itself comes in two flavors, and the curl-like mode is the one most operators will reach for first. Running vulnapi scan curl [API_URL] [CURL_OPTIONS] lets you replicate an authenticated session by pasting in the same headers, cookies, and methods you would use with curl itself — a pragmatic approach that avoids forcing you to model the target before testing it. This is the pattern popularized by tools like feroxbuster and nuclei: meet the operator at the command line they already know. For pipelines, the second mode consumes an OpenAPI contract directly, either from a local path or URL, and supports piping a JWT in via --token-stdin rather than embedding it in shell history — a small but appreciated security-conscious touch.
The output format deserves attention because it is clearly built for human triage and CI parsing alike. Findings are rendered in a table keyed by operation (GET /, GET /books/v1), with columns for risk level, CVSS 4.0 score, the mapped OWASP category, and a plain-language description. The use of CVSS 4.0 rather than the ubiquitous 3.1 signals the project is keeping current with scoring standards, and mapping each finding to API8:2023 Security Misconfiguration rather than a custom taxonomy makes results immediately actionable for teams tracking compliance against the OWASP API Security Top 10.
The README's example output is dominated by header-hygiene findings — missing X-Frame-Options, missing CORS headers, absent Content-Security-Policy and frame-ancestors, missing HSTS, and missing X-Content-Type-Options. Individually these are low-to-medium severity items, but the tool also flags an operation that "May Accepts Unauthenticated Requests," which is the more operationally interesting signal: it points at broken authorization boundaries, the class of flaw (API1/API2 in OWASP terms) that actually breaches data in real incidents. The full catalog of detected vulnerabilities lives on the project's documentation site rather than in the README, and the authors note more checks are planned, inviting issues and pull requests.
The jwt subcommand is a distinguishing feature worth dwelling on even though the README gives it only a single line. Combined with the discover output for jwks.json endpoints and the topics list (jwt, authentication, authorization), it paints a picture of a scanner built with identity flows as a first-class concern rather than an afterthought. Being able to generate test tokens in-tool means an operator can exercise authenticated endpoints across different claims and roles without leaving the workflow, which is exactly how you probe for privilege escalation paths in a controlled environment.
Network plumbing is handled the way a Go tool should handle it: proxy support via the standard HTTP_PROXY and HTTPS_PROXY environment variables, plus a --proxy flag for per-invocation overrides. This matters more than it seems, because routing a DAST through an intercepting proxy such as a local listener lets you observe exactly what the scanner sends — essential for verifying behavior in a lab and for debugging rate limits or authentication quirks during an authorized engagement. Every scanner should offer this; many don't.
One genuinely notable disclosure in the README is the telemetry section: the tool collects anonymous usage data including scan counts, vulnerability counts, and severity distribution, and it can be disabled with --sqa-opt-out. The authors state no sensitive information is collected, and the scope described is plausibly benign, but operators on sensitive engagements should default to the opt-out flag as a matter of hygiene. It is also a defensive-relevant fact: knowing a scanner phones home means understanding your egress profile when running it inside a client environment.
The credits section reveals the project's building blocks and therefore its likely expansion path: SecLists for the well-known-path and leaked-file wordlists behind discover, wappalyzergo for fingerprinting, and the authors' own jwtop for JWT handling. This composition of proven components rather than bespoke implementations is a maturity signal — the risky parts (request handling, pattern lists, tech detection) are delegated to battle-tested libraries. A serve subcommand implies a server mode beyond the CLI, though the README doesn't elaborate, and a Discord community badge plus release automation suggest an actively maintained project rather than a weekend artifact.
In an authorized workflow, vulnapi slots in best as the automated first pass: run discover to map exposure, feed the OpenAPI contract into scan in CI, and let the CVSS-scored, OWASP-mapped output drive ticket creation. Its finding set skews toward misconfiguration and authentication posture rather than deep business-logic fuzzing, so treat it as coverage for the cheap, common, high-frequency flaws — the ones that should never reach production — and reserve manual testing for logic-level abuse cases. The disclaimer in the README is explicit that the tool is for educational and informational purposes and must not be used against systems without proper authorization, which is both the correct posture and the correct operating constraint.
For defenders, the tool's footprint is straightforward: it generates ordinary HTTP request patterns — well-known path probes, header checks, repeated authenticated calls — that appear in access logs and can be baselined in lab runs to build detection signatures for unauthorized copies. Nothing about it is covert by design. That transparency, combined with MIT licensing and readable Go source, makes vulnapi equally useful as a blue-team reference for what an API scanner's traffic looks like and as a red-team-adjacent quality gate for teams shipping APIs responsibly.
cerberauth/vulnapi.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.