Metlo: Building an Open-Source API Security Platform That Actually Respects Your Data
Hook
While API breaches jumped 200% last year, most security tools require you to send all your API traffic to someone else’s cloud. Metlo takes a different approach: keep your data on your infrastructure while still getting real-time attack detection.
Context
The explosion of public-facing APIs has created a security nightmare. Companies like Uber, Meta, and Experian have leaked millions of records through API vulnerabilities, yet the tooling landscape remains frustrating. Enterprise solutions hide behind sales calls and require exfiltrating your traffic to their clouds—a non-starter for regulated industries or privacy-conscious teams. Open-source alternatives often provide basic monitoring but lack the sophisticated attack detection and testing frameworks security teams actually need.
Metlo emerged from this gap: an MIT-licensed API security platform you can self-host in under 15 minutes. It combines passive traffic analysis for endpoint discovery with active security testing, all while keeping your data entirely within your infrastructure. The architecture appears similar to commercial tools like Traceable AI or Salt Security but without the vendor lock-in or data residency concerns. For teams dealing with GDPR, HIPAA, or simply wanting control over their security posture, this matters more than any feature checklist.
Technical Insight
Metlo’s architecture is built in TypeScript and follows a distributed model with agents that monitor traffic and a backend for processing. Agents operate at ingestion points across AWS, GCP, Azure, or Docker environments, enabling the platform to perform endpoint discovery, sensitive data scanning, and attack pattern detection.
The passive traffic analysis operates by scanning network traffic to inventory API endpoints without requiring SDK integration or code changes. Each discovered endpoint gets scanned for PII data and assigned a risk score. The processing happens in your infrastructure—traffic is analyzed locally to build attack detection models from observed patterns. An optional cloud detection engine can provide threat intelligence metadata, but the actual traffic remains in your environment.
What sets Metlo apart is its YAML-based security testing framework. Rather than relying solely on passive detection, you can codify OWASP API security tests as executable specifications. Here’s a real example from their documentation testing for broken authentication:
id: test-payment-processor-metlo.com-user-billing
meta:
name: test-payment-processor.metlo.com/user/billing Test Auth
severity: CRITICAL
tags:
- BROKEN_AUTHENTICATION
test:
- request:
method: POST
url: https://test-payment-processor.metlo.com/user/billing
headers:
- name: Content-Type
value: application/json
- name: Authorization
value: ...
data: |-
{ "ccn": "...", "cc_exp": "...", "cc_code": "..." }
assert:
- key: resp.status
value: 200
- request:
method: POST
url: https://test-payment-processor.metlo.com/user/billing
headers:
- name: Content-Type
value: application/json
data: |-
{ "ccn": "...", "cc_exp": "...", "cc_code": "..." }
assert:
- key: resp.status
value: [ 401, 403 ]This test makes two requests: one authenticated (expecting HTTP 200) and one without credentials (expecting 401 or 403). The YAML format is declarative enough for security teams to read but executable for CI/CD integration. You can autogenerate tests for common vulnerabilities like BOLA (Broken Object Level Authorization), SQL injection, and authentication bypasses, then customize them for your specific API contracts.
The attack blocking mechanism works by having the backend identify malicious actors from traffic patterns, then agents pull this metadata to block malicious requests in real time. This approach keeps detection centralized while pushing enforcement to where traffic enters your infrastructure.
Deployment options span AWS, GCP, Azure, and Docker, making it infrastructure-agnostic in practice. The platform can be set up in under 15 minutes according to the documentation.
Gotcha
The open-source version has significant limitations that aren’t immediately obvious from the feature list. User management, user roles, and attack protection require an enterprise license—the MIT-licensed code handles detection and testing, but if you want automated blocking and access controls, you need to contact the vendor. This licensing model isn’t unusual (it’s similar to GitLab’s approach), but understanding which features cross this boundary is critical before deployment.
The platform requires network-level traffic access, which may add deployment complexity depending on your infrastructure. The documentation provides deployment guides for major cloud providers but doesn’t include performance benchmarks or guidance on sizing agents for high-throughput APIs. If you’re handling millions of requests per minute, you’ll need to test capacity yourself.
The attack detection models are described as being “built on patterns of malicious requests” but the repository doesn’t document training data, false positive rates, or model versioning. For a security tool, this opacity is problematic—you need to understand what might slip through and what legitimate traffic might get flagged. Without this visibility, evaluating whether the detection quality matches your risk tolerance requires hands-on testing.
Verdict
Use Metlo if you need comprehensive API visibility across multiple cloud providers, want security testing integrated into CI/CD pipelines, and have strong data residency requirements that make SaaS solutions non-viable. The self-hosted model and YAML testing framework provide real value for teams that can handle the operational overhead. It’s particularly well-suited for regulated industries (finance, healthcare) where sending API traffic externally isn’t an option, and for security teams that want to codify OWASP API tests without building everything from scratch. Skip it if you need production-grade attack blocking without enterprise licensing, require a battle-tested solution with transparent detection models and proven scale, or are looking for basic API monitoring where simpler tools like Kong Gateway with security plugins might suffice. The platform shows promise but requires careful evaluation of the enterprise feature boundaries and deployment complexity for your specific use case.
