Buchi Reddy B
CEO and Founder at Levo
.svg)
As we take Levo.ai mainstream in the enterprise world, we often encounter questions that challenge the need for an API Lifecycle and Security product like ours if a customer is already using other tools
Given that the market is saturated by tools such as service meshes, WAFs, DAST and SAST tools, and API Gateways, it's a valid concern.
This blog aims to educate our audience on how our API Lifecycle Platform adds significant value to DevSecOps teams, often complementing—and sometimes replacing—legacy products.
Today, we'll focus on API Gateways. Many prospects ask, "We already have AWS API Gateway installed, why do we need Levo?"
We'll address this question by explaining how Levo performs five core functions to keep APIs secure—functions that API Gateways lack.
Don’t get me wrong, I love API Gateways just as much as any other Engineering Leader.
When I led Engineering teams at growing startups, we greatly benefited from their ability to automatically transform requests, authenticate, and provide robust monitoring.
API Gateways centralized our systems, simplified processes, and made our DevSecOps team incredibly efficient.
Developers no longer needed to manually implement authentication, rate limiting, request transformation, and error handling for every service or manage versions. Security Analysts were spared from manually auditing each service. This allowed us to focus on what mattered most—deploying features at lightning speed with minimal manual testing.
Since then, API Gateways have evolved significantly. Most now offer data masking and redaction, WAF integrations, OAuth, and OpenID Connect support.
So why is a platform like ours needed?
No Gateway provides what forms the bedrock of API Security—API Visibility. Without it, most WAF and Attack alerts lack context and become inactionable.
Let's explore several such limitations that Levo can help you overcome.
The bedrock of API Security is API Visibility.
Whether in production or earlier in the SDLC, knowing your endpoints and their context is crucial. Without understanding how many APIs you have and their location within your network, alerts can't be contextualized or acted upon effectively.
Here’s how API Gateways fall short of the components of API Visibility:
Typically deployed at the edge of your network, Gateways perform rate-limiting, load balancing, and several other functions to manage and secure passing traffic. They have visibility into APIs routed through them.
But what about APIs that are not routed through them?
Gateways are essentially blind to these, and that includes internal APIs, partner APIs, and third-party and open-source APIs:
Contrary to popular belief, your internal, partner, and third-party APIs are just as susceptible to security incidents as external ones. In fact, due to neglect, they're more likely to be targeted by attackers seeking an entry point into your system.
This is particularly true for fintech and healthcare enterprises, whose networks largely comprise partner and third-party APIs.
The Gateway's discovery limitations don't end there. They also miss a significant amount of your external APIs. Their edge-centric design focuses on incoming network traffic but overlooks traffic originating from within your network or other external services.
Many of our clients report that Gateways miss over 85% of their traffic, severely compromising the coverage of their API Inventory.
Most API Gateways do not provide documentation at all.
A few have started to, but how comprehensive can such documentation be if the Gateway misses most APIs within your network?
While Gateways can log API usage, they're not equipped to capture most API parameters.
So, documentation—even for discovered APIs—contains only basic metadata like endpoint names and HTTP methods, rendering it incomplete. Comprehensive and useful documentation should include these parameter details:
Many API Gateways now claim to perform data masking and redaction through policy-based configuration. Configuring these policies across APIs can be a mammoth and often ineffective undertaking. Even if your team manages to configure them, redaction is not certain.
As APIs transmit data in complex, nested, and varying formats, making sensitive data identification impossible with predefined patterns. This redaction heavily relies on API Documentation to identify sensitive data fields—which, as we established, a Gateway can't provide.
Moreover, sensitive data flowing through non-external APIs might bypass masking and redaction entirely, leaving it exposed and compromising compliance efforts. The same would happen with newer APIs deployed without reconfiguring the Gateway or APIs that are frequently updated or modified.
For any Gateway to consistently mask sensitive data across all possible permutations of formats, varying contexts, and embeds, a thorough assessment would be needed. This assessment should enable an understanding of how sensitive data flows are created within internal APIs or between microservices.
Since API Gateways operate at the application level without a full understanding of the business logic of each API endpoint, they can't detect—and consequently can't protect—sensitive data flows.
At this point, most engineering and security leaders would agree that pre-production API testing is crucial to safeguard against API-induced breaches.
While API Gateways offer integrations with functional testing tools, they lack dedicated security testing capabilities.
Initial tests validate API functionality and performance, but real-world scenarios demand negative testing.
Security testing is essential to identify how APIs handle malicious or unexpected inputs, simulating potential attacks to uncover vulnerabilities.
Without this, relying solely on API Gateways exposes enterprises to significant risks, as these tools can't protect against complex AuthZ, AuthN vulnerabilities, and business logic attacks.
To read more about API Security Testing, check out these two blogs that define what is API Security Testing and how you can automate it.
All of this while being completely passive and out-of-line. So you don't have to worry about us adding latency or disrupting your operations.
Book a demo through this link to see this in action!
.png){kind=logo}
.svg)
.svg)
