Akto is an open source API security platform that builds a continuous inventory of APIs from mirrored traffic and runs automated business logic tests against them for authorized security teams.
| Tool | akto-api-security/akto — open source API security platform for inventory, testing, and runtime analysis, with AI agent and MCP security coverage |
| Category | API security testing and inventory platform (Java, MIT-licensed) |
| Primary Use | Maintaining continuous API inventory from traffic sources like Burp Suite, AWS, Postman, and GCP, then running business logic tests in CI/CD against those collections |
| Safe Use | Deploying against APIs you own or are explicitly authorized to assess; the tool is designed for internal security and engineering teams hardening their own services |
| Telemetry Note | Akto's active tests generate HTTP requests against target collections, so expect its test traffic (including probe payloads for SSRF, BOLA, and auth checks) to appear in application and WAF logs; mirrored traffic analysis itself is passive |
Akto positions itself as an instant, open source API security platform, and the emphasis on speed is more than marketing: the maintainers claim a roughly sixty-second path from deployment to a working dashboard via docker-compose. What you actually get is a three-stage pipeline — build an API inventory from observed traffic, run automated tests against the discovered endpoints, and surface runtime issues such as sensitive data exposure. The project, hosted at akto-api-security/akto and MIT-licensed, has accumulated over fifteen hundred stars and a Java codebase that has been demonstrated publicly at Black Hat Arsenal USA 2023 and DEF CON 2023, which is a reasonable signal of community traction for a defensive tooling project.
The repository's topic tags tell you where the project is heading: alongside classic API security concerns, akto now advertises coverage for AI-specific risk — ai-security, guardrails, red-teaming, and explicit alignment with the OWASP LLM Top 10, OWASP Agentic Top 10, and OWASP MCP Top 10 drafts. That means the platform is being extended from traditional REST-facing API testing toward securing AI agents and MCP (Model Context Protocol) integrations, which is where a lot of authorized red-team and appraisal work is currently focused. For teams already running LLM-backed services, this framing makes akto relevant well beyond its original API-scanning niche.
Internally, the architecture is a fairly conventional three-tier Java application. The dashboard backend is built with Maven and Jetty, serving on port 9090, with a Vue.js/npm frontend under apps/dashboard/web/polaris_web. State lives in MongoDB (v5.0.3+ per the README), connected via the AKTO_MONGO_CONN environment variable, and the testing engine is a separate module under apps/testing with its own entry point at com.akto.testing.Main. This separation matters operationally: the testing module can be invoked independently of the dashboard, which is what enables the CI/CD integration the project advertises.
Inventory building is the foundation of everything else akto does. Rather than crawling, it ingests traffic from multiple sources — the README lists Burp Suite, AWS, Postman, GCP, and API gateways — and reconstructs endpoint collections from what real clients actually call. This traffic-derived approach tends to produce more accurate inventories than specification-driven scanning because it captures shadow endpoints and undocumented parameters that never made it into an OpenAPI document. For an authorized assessment, that inventory alone is often the most valuable deliverable, since most organizations cannot enumerate their own API surface reliably.
The testing engine is where akto differentiates itself from generic scanners. The README states that it reads traffic data to understand API traffic patterns before running business logic tests, explicitly citing reduced false positives as the outcome. Test categories cover the OWASP Top 10 and HackerOne Top 10, including BOLA, authentication flaws, SSRF, XSS, and security misconfigurations. The published tutorial on SSRF port scanning mapped to OWASP API7:2023 gives a concrete sense of how tests are framed around specific API weaknesses rather than generic web vulns.
The Testing CLI is the component an authorized operator will most likely script into a pipeline. It ships as the Docker image aktosecurity/akto-api-testing-cli and is driven entirely by environment variables: TEST_IDS selects named tests (the README shows JWT_NONE_ALGO and REMOVE_TOKENS as examples), API_COLLECTION_ID scopes execution to an inventory collection, TEST_APIS narrows to specific endpoints, and OVERRIDE_APP_URL lets you point the same test suite at a staging host instead of production. Mounting the working directory to /out produces a test report on the host, which is how results feed back into CI/CD gates.
Deployment is deliberately simple for local evaluation: clone the repository, cd akto, then docker-compose up -d, and the dashboard appears on localhost:9090 with a first-run signup flow. What is more interesting is that the README includes a hardening section for cloud deployments — restrict inbound rules on port 9090 to your VPC CIDR, prefer a private-subnet EC2 reached through an ssh -L tunnel, and explicitly warns against public-subnet exposure. It is a good sign when a security tooling vendor documents secure deployment of its own console, and it is advice worth following, since the dashboard becomes a map of your entire API surface if compromised.
For development and contribution, the project offers a VS Code Dev Container path that collapses the whole Java/node/MongoDB stack into a reproducible environment, alongside the manual setup documented in full detail — OpenJDK 8, node v18.7.0+, npm, Maven 3.6.3, and MongoDB all started by hand. The debugging section, including MAVEN_OPTS flags for a jdwp debug socket on port 8081 and JMX metrics on 9010, suggests the maintainers expect meaningful outside contribution, and the CONTRIBUTING.md and Discord community reinforce that.
The enterprise tier adds mirrored traffic ingestion with what the README describes as zero performance impact on the application, scheduled CI/CD testing, and multi-user dashboards. The open source core remains genuinely usable — inventory, test library, and the CLI are all in the repository — but teams comparing it against commercial API security platforms should understand that the cloud traffic mirroring and team workflow features sit behind the paid edition at stairway.akto.io.
From a defensive telemetry standpoint, it is worth remembering that akto's active tests are visible to the systems they probe. If you run it against your own staging or production APIs, expect WAF and application logs to fill with recognizable test patterns — auth manipulation, token removal, and SSRF callbacks — and coordinate with the teams who monitor those logs before scheduling runs. The passive inventory ingestion from mirrored Burp or gateway traffic, by contrast, leaves no footprint on target systems at all, which makes that half of the platform safe to run continuously.
Where akto fits best in an authorized workflow is as the connective tissue between traffic observation and regression testing: discovery feeds collections, collections feed named tests, and tests gate merges in CI/CD. The expansion into OWASP LLM/MCP/agentic coverage makes it one of the earlier open source platforms treating AI-agent endpoints as a first-class API security surface rather than an afterthought, and that alone justifies a look from teams whose API estate now includes model-backed services.
akto-api-security/akto.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.