Inside Akto: How Traffic-Based API Discovery Outperforms Traditional Security Scanning
Hook
Most API security tools need you to tell them what endpoints exist. Akto flips this model: it watches your traffic for 60 seconds and tells you what APIs you forgot you had—then tests them for vulnerabilities you didn’t know existed.
Context
API security has traditionally been an afterthought bolted onto web application security scanners. You’d write OpenAPI specs, maintain Postman collections, or manually configure endpoint lists—only to watch them become outdated the moment a developer ships new code. The problem compounds in microservices architectures where APIs proliferate faster than security teams can document them.
Akto takes a fundamentally different approach: it assumes your API inventory is always incomplete and treats traffic as the source of truth. By passively analyzing API calls in production or staging environments, it builds a living inventory that updates automatically. This shift from specification-driven to observation-driven security mirrors how modern monitoring evolved from static configs to dynamic service discovery. The result is a security platform that covers OWASP API Top 10 and HackerOne Top 10 vulnerabilities—including BOLA, authentication flaws, and sensitive data exposure—without requiring teams to maintain documentation that’s obsolete before the PR merges.
Technical Insight
Akto’s architecture centers on a traffic analysis pipeline that feeds three core systems: inventory management, security posture assessment, and active testing. The platform supports multiple traffic sources—AWS traffic mirroring, GCP packet mirroring, API gateway logs, Burp Suite proxies, and Postman collections—ingesting them into a data store where traffic patterns are processed.
The platform builds context from traffic by clustering API calls by endpoint structure, analyzing parameter types and relationships, and inferring authentication schemes. When you deploy Akto using the included Docker Compose setup, the system processes traffic to automatically discover and catalog your APIs.
Here’s how you’d get started with traffic-based discovery:
# Clone and start Akto
git clone https://github.com/akto-api-security/akto.git
cd akto
docker-compose up -d
# Access dashboard at http://localhost:9090
# Traffic sources can be configured via the UIOnce traffic flows in, Akto examines each API call to extract metadata: HTTP methods, path patterns with variables, request/response schemas, authentication headers, and data types. This information populates the inventory automatically. If you have an endpoint like GET /api/users/{userId}/orders/{orderId}, Akto appears to identify the path variables, recognize the resource hierarchy, and catalog the data types returned.
The testing engine leverages this traffic intelligence to generate contextual security tests. Unlike static scanners that blast generic payloads at endpoints, Akto constructs tests based on observed behavior. For example, if it sees User A accessing /api/users/123/orders and User B accessing /api/users/456/orders, it can generate BOLA (Broken Object Level Authorization) tests by attempting cross-user access: can User A reach /api/users/456/orders?
Akto ships with 1000+ pre-built tests covering OWASP categories, and the platform supports adding custom tests. Tests run in two modes: passive analysis during traffic observation and active scanning triggered manually or in CI/CD pipelines. The test library includes checks for authentication bypass, authorization flaws, injection attacks, security misconfigurations, sensitive data exposure in responses, and business logic vulnerabilities.
The CI/CD integration allows you to schedule tests and run them in your pipeline. When tests run, they can leverage endpoint patterns and parameter types learned from traffic, potentially reducing false positives compared to generic DAST tools that don’t understand your API’s behavior.
One architectural consideration: Akto requires continuous or periodic traffic capture to maintain accuracy. For production deployments, this means setting up traffic mirroring (which the README notes has zero performance impact but requires infrastructure configuration). The README emphasizes cloud deployment through their Enterprise edition for features like scheduled CI/CD tests and team collaboration, though the open-source version handles the core discovery and testing workflows locally.
Gotcha
Traffic-based discovery is Akto’s strength and its constraint. You need active traffic to discover APIs, which means newly deployed endpoints won’t appear in your inventory until someone calls them. If you’re testing a greenfield API or validating endpoints before production deployment, you’ll need to generate traffic manually or import specifications—somewhat defeating the automatic discovery benefit.
The Docker Compose deployment is straightforward for local testing (taking 60 seconds to get started as advertised), but production deployment complexity requires careful attention. The instructions mention cloud deployment and features like CI/CD scheduling require the Enterprise edition available at stairway.akto.io, suggesting the open-source version has functional limitations for team workflows. The README also warns about security configurations for cloud deployments (restricting port 9090, using private subnets, setting up VPN tunneling) but doesn’t provide detailed hardening guidelines beyond basic recommendations.
Resource consumption is another consideration. The README doesn’t specify memory or CPU requirements, though the Docker image size badge indicates a substantial footprint. If you’re analyzing high-volume API traffic, you’ll need to provision accordingly and potentially optimize the deployment beyond the default docker-compose.yml configuration.
Verdict
Use if you manage sprawling API surfaces across microservices where manual inventory maintenance is impossible, need business logic testing that understands your API patterns rather than just throwing OWASP payloads at endpoints, want to integrate security testing into CI/CD with context from production traffic, or operate in environments where traffic mirroring infrastructure is already available. Akto excels when your API landscape is dynamic and documentation lags reality. Skip if you have a small, well-documented API where maintaining specifications is manageable, need fully offline security testing without traffic capture dependencies, require enterprise features like team collaboration and scheduled testing but can’t use the commercial offering, or operate in resource-constrained environments where running the full stack may not be feasible. Also skip if you’re building APIs from scratch and need design-time security validation before any traffic exists—specification-driven tools would serve you better in that scenario.
