Metlo: The Open-Source API Security Platform That Watches Your Traffic

Hook

Most organizations don't know what APIs they're running in production. Metlo discovered that 40% of endpoints in tested environments were completely undocumented—shadow APIs processing real customer data with zero security oversight.

Context

API security has become the soft underbelly of modern applications. While traditional application security focuses on web UIs and known attack surfaces, APIs multiply like rabbits—microservices spawn new endpoints, third-party integrations add external attack vectors, and developers ship changes faster than security teams can document them. The 2023 API security landscape is grim: APIs account for 83% of web traffic, yet most organizations lack basic inventory of what endpoints exist, what data they expose, and whether they're vulnerable.

Traditional approaches fail because they're reactive. Pen-testing happens quarterly. OWASP Top 10 checklists get run before major releases. WAFs protect known endpoints with manually configured rules. Meanwhile, a developer deploys a new microservice on Friday afternoon with an endpoint that accidentally leaks customer emails, and nobody notices for months. Metlo emerged from this gap—the realization that API security needs continuous, automatic discovery married to real-time threat detection. It's not enough to test what you know about; you need to discover what you don't know, then protect it.

Technical Insight

Metlo's architecture revolves around a distributed agent model that feels more like network security tooling than traditional application security. The agents deploy as sidecars (Kubernetes), inline proxies (AWS API Gateway), or packet capture daemons that sit at the network level, passively observing HTTP/HTTPS traffic. They're not proxies that slow down your requests—they mirror traffic asynchronously, parsing requests and responses to build an API inventory.

Here's how you'd deploy the agent in a Kubernetes cluster using a DaemonSet:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: metlo-agent
  namespace: metlo
spec:
  selector:
    matchLabels:
      app: metlo-agent
  template:
    metadata:
      labels:
        app: metlo-agent
    spec:
      hostNetwork: true
      containers:
      - name: metlo-agent
        image: metlo/agent:latest
        env:
        - name: METLO_HOST
          value: "https://your-metlo-backend.com"
        - name: METLO_KEY
          valueFrom:
            secretKeyRef:
              name: metlo-credentials
              key: api-key
        securityContext:
          capabilities:
            add: ["NET_ADMIN", "NET_RAW"]
        volumeMounts:
        - name: host-proc
          mountPath: /host/proc
          readOnly: true
      volumes:
      - name: host-proc
        hostPath:
          path: /proc

The agent uses packet capture (libpcap under the hood) to intercept traffic without modifying it. It reconstructs HTTP transactions, extracts metadata—endpoints, headers, request bodies, status codes—and streams this data to the central Metlo backend. The genius here is what happens next: the backend doesn't just log requests. It builds behavioral models.

Metlo's detection engine performs several analysis passes. First, it discovers endpoints automatically, clustering similar paths (/users/123 and /users/456 become /users/{id}). Second, it scans for sensitive data using regex patterns and ML-based classification—PII, credit cards, API keys, auth tokens. Third, it establishes baseline behavior: what parameters are expected, what response codes are normal, what rate of requests is typical. When deviations occur—a sudden spike in 401s suggesting credential stuffing, a request with SQL injection patterns, an endpoint returning sensitive data it never exposed before—Metlo flags it.

The testing component operates differently. You define security tests in YAML that Metlo runs during CI/CD:

meta:
  name: "BOLA Test - User Endpoints"
  severity: HIGH
  tags: ["OWASP-API1", "authorization"]

test:
  - request:
      method: GET
      path: "/api/users/{user_id}"
      headers:
        Authorization: "Bearer ${USER_TOKEN}"
    validate:
      status: 200
  
  - request:
      method: GET
      path: "/api/users/{OTHER_USER_ID}"
      headers:
        Authorization: "Bearer ${USER_TOKEN}"
    validate:
      status: [401, 403]
      not_contains:
        - "${OTHER_USER_EMAIL}"

This test checks for Broken Object Level Authorization (BOLA)—can user A access user B's data? The framework injects different tokens and validates that authorization boundaries hold. You're essentially codifying pen-test scenarios that run on every deployment.

The blocking mechanism is where the distributed architecture pays off. When the central engine identifies malicious patterns, it generates blocking rules that agents pull down via a lightweight API. Agents then enforce these rules at the edge—rejecting requests before they hit your application servers. This hybrid approach keeps detection logic centralized (easier to update, train models) while keeping enforcement distributed (low latency, no single point of failure).

Metlo stores everything in PostgreSQL with a time-series optimization layer for traffic data. The web UI is a React/TypeScript SPA that queries the backend's GraphQL API, rendering endpoint maps, vulnerability dashboards, and traffic analytics. For teams wanting to extend it, the GraphQL schema is well-documented, and you can build custom integrations that query discovered APIs or subscribe to security events.

Gotcha

The 'self-hosted' claim needs an asterisk. While you deploy Metlo's components in your infrastructure, the architecture assumes agents send traffic metadata to a centralized backend. For organizations with strict data residency requirements or air-gapped environments, this is a non-starter. You're not sending full request bodies by default, but metadata includes paths, headers, and parameter names—enough to make compliance officers nervous. There's no fully offline mode where agents operate autonomously.

The enterprise licensing model undercuts the open-source value proposition in production scenarios. The blocking capabilities—arguably the most critical feature for actual security—require an enterprise license. Same with user management and SSO. The free version gives you discovery and detection, but you can't automatically stop attacks without paying. This makes the open-source edition more of a reconnaissance tool than a comprehensive security platform. For staging environments or security research, it's perfect. For production blocking at scale, budget for licensing. Also worth noting: GitHub activity suggests development has slowed, with sporadic commits in recent months. This could indicate the team has shifted focus to commercial offerings, which is common in open-core models but raises sustainability questions for the free version.

Verdict

Use if: You need rapid API discovery across microservices architectures where documentation lags reality, you're building an API security program from scratch and want an open-source foundation to customize, you're running security testing in CI/CD and want YAML-defined test cases for OWASP API Top 10 vulnerabilities, or you're okay with the hybrid architecture that centralizes detection while distributing enforcement. It's particularly strong for startups and mid-size companies in development/staging environments where the enterprise features aren't critical yet. Skip if: You require fully air-gapped deployment without any centralized backend communication, you need production-grade attack blocking without enterprise licensing costs, you want active development with frequent updates and community engagement, or you're in a regulated industry where sending any traffic metadata outside your security boundary violates compliance. In those cases, look at commercial alternatives like Traceable AI for mature threat detection, or build custom solutions on top of Envoy/Istio service meshes with OPA for policy enforcement.