.jpg)
.svg)
APIs have become the operational backbone of modern digital enterprises. They power mobile applications, cloud platforms, partner integrations, payment systems, and increasingly, AI driven workflows. As organisations expand their digital reach, they also expand their API attack surface. Yet many enterprises continue to rely on the same perimeter controls they used for web applications, assuming that an API gateway and a web application firewall are sufficient to manage this risk.
The data suggests otherwise.
Gartner estimates that by the end of 2025, more than half of all data breaches will involve APIs, making them the most targeted attack surface in modern application stacks. This shift reflects how business value now flows through APIs. Customer records, payment details, order histories, and operational data are no longer accessed through web pages. They are accessed through machine to machine interfaces designed for speed and automation.
Postman’s State of the API Report shows that over 90% of organisations now depend on APIs for revenue generating workflows, including partner onboarding, customer acquisition, and transaction processing. APIs are no longer technical plumbing. They are business infrastructure. When APIs fail or are abused, revenue, customer trust, and regulatory compliance are all impacted at once.
The financial consequences of this exposure are rising. IBM’s 2024 Cost of a Data Breach Report found that the average global breach now costs USD 4.88 million, with incidents involving customer data and regulatory notification driving the largest increases. API related breaches tend to be particularly expensive because they often involve large scale data extraction rather than isolated system compromise.
Despite this, many organisations continue to equate API security with traffic control. API gateways manage routing, authentication, and rate limits. WAFs inspect requests for malicious patterns. Both are important. Neither was designed to understand how business logic, object ownership, and sensitive data actually behave inside APIs.
From a business perspective, this creates a dangerous blind spot. Enterprises believe they have invested in security, yet they remain exposed to abuse scenarios that perimeter tools cannot see. Customer data can be enumerated through legitimate endpoints. Privileged functions can be accessed through misconfigured roles. Sensitive records can be exfiltrated without triggering signature based defenses.
This gap between perceived protection and real exposure is why API breaches continue to rise even in highly secured environments. Understanding the difference between what API gateways and WAFs are built to do, and what modern API security actually requires, is now a critical business and risk management priority.
What is an API Gateway?
An API gateway is a control plane that sits in front of backend services and manages how API requests are received, routed, and processed.
At a basic level, it acts as a single entry point for all API traffic. Instead of clients calling multiple services directly, they send requests to the gateway, which then forwards those requests to the appropriate internal service. This allows enterprises to centralize functions such as authentication, request routing, protocol translation, rate limiting, and basic logging.
From a business and operations perspective, the API gateway is designed to support reliability, scalability, and developer experience. It helps ensure that APIs are available, that traffic is balanced across services, that clients are authenticated, and that abusive or accidental overuse is throttled.
What it does not do is determine whether a request is logically valid, whether a user is allowed to access a specific data object, or whether the data being returned is appropriate for that caller. Those decisions are left to the application and its underlying services.
In other words, an API gateway manages how requests reach APIs. It does not understand what those APIs are actually doing with data once the request is inside.
How does API Gateway work?
At a high level, an API gateway works like a managed front door for your APIs. Instead of every client calling every backend service directly, all requests hit the gateway first. The gateway then applies a standard set of controls and forwards the request to the right service.
Here is the typical flow.
A client calls the gateway, not the service
A mobile app, web frontend, or partner integration sends an API request to the gateway endpoint. This keeps internal services off the public internet and gives the enterprise one consistent entry point.
The gateway verifies identity
The gateway checks credentials such as API keys, JWTs, or OAuth tokens. If the request is not authenticated, it is rejected before it touches backend systems.
The gateway applies traffic controls
It enforces rate limits, quotas, and throttling so a single client cannot overwhelm services. Many gateways also enforce basic request constraints like maximum payload size or allowed methods to reduce accidental misuse and blunt simple abuse patterns.
The gateway routes the request to the correct backend
Based on routing rules, the gateway forwards the request to the right microservice or application. This is often based on the URL path, version, or HTTP method.
The gateway handles protocol and format concerns
In many environments, the gateway can translate protocols, normalize headers, or perform lightweight transformations so backend services do not need to support every client variation.
The gateway records the transaction
It generates logs and metrics such as request volume, latency, and error rates. This is primarily operational visibility rather than security visibility into business logic.
The key point is that an API gateway is excellent at managing how requests enter the system. It is not designed to validate whether the request is logically allowed for a specific object, role, or data record once the request reaches the application.
Architecture
Architecturally, the API gateway sits between clients and backend services as a centralized control layer. All external and partner traffic enters through this layer before it is allowed to reach any internal application or microservice.
In most modern deployments, the gateway is placed at the edge of the application environment, either in front of a cloud load balancer or directly integrated with it. Client applications connect only to the gateway. They never see the actual service endpoints. This allows the enterprise to expose a single, stable API surface while backend services can be added, removed, or restructured without breaking clients.
Behind the gateway, requests are routed to internal services that run inside private networks, Kubernetes clusters, or service meshes. These services implement the actual business logic and data access. The gateway does not participate in those operations. It only decides where the request should go and whether it is allowed to proceed based on predefined rules.
The gateway is typically integrated with identity providers so it can validate OAuth tokens, API keys, or JWTs before forwarding traffic. It also connects to logging and monitoring systems to provide metrics on request volumes, latency, and error rates. This gives operations teams visibility into how APIs are being used, but not into how individual data objects or business rules are applied inside services.
This architecture makes the API gateway highly effective at managing access and traffic at the perimeter. It also means that once a request passes through the gateway, control is handed off to the application layer, where most API security failures actually occur.
What is WAF?
A Web Application Firewall, or WAF, is a security control that sits in front of web applications and inspects HTTP and HTTPS traffic to detect and block malicious activity. It operates at the application layer and evaluates incoming and outgoing requests against a set of security rules before those requests reach the application.
In practical terms, a WAF acts as a filtering and enforcement layer between users and web servers. It looks for known attack patterns such as SQL injection, cross site scripting, command injection, and protocol abuse. When a request matches one of these patterns, the WAF blocks or challenges it before it can interact with the application.
Modern WAFs have evolved to handle API traffic in addition to traditional web page requests. They can parse JSON and XML payloads, understand REST and GraphQL calls, validate request structure, and apply security rules to individual fields within an API request. These API aware WAFs are designed to protect endpoints from common API threats such as injection attacks, excessive data exposure, and basic authorization abuse.
At its core, however, a WAF remains a perimeter control. It focuses on inspecting traffic at the edge of the application to block known bad patterns and enforce protocol level correctness. It does not understand how business logic is implemented inside services or how data ownership and access rules are enforced once a request has been accepted.
How does WAF work?
A WAF works by inspecting application traffic at the edge and blocking requests that match known attack patterns or violate defined rules. Instead of letting requests hit the application directly, it places a security checkpoint in front of the app or API.
Here is the typical flow.
A request reaches the WAF first
Every HTTP or HTTPS request from a browser, mobile app, or API client is routed through the WAF before it can reach the application.
The WAF inspects what is inside the request
It examines the URL, headers, query parameters, cookies, and the request body. For APIs, modern WAFs can parse JSON, XML, and GraphQL payloads so that inspection happens at the field level, not just as raw text
The WAF evaluates the request against security rules
These rules can be signature based, such as detecting SQL injection or cross site scripting patterns, and can also include protocol enforcement rules like blocking malformed requests. Many modern WAFs also support schema enforcement, where the request must conform to an expected API structure
The WAF blocks, challenges, or allows the request
If a rule is triggered, the WAF can block the request, throttle it, or issue a challenge. If the request passes inspection, it is forwarded to the application or API service.
The WAF logs what happened
It records which rule was triggered, which endpoint was targeted, and other request metadata. This is useful for monitoring and incident response, but the logging is still limited to what the WAF can observe at the perimeter.
The key point is that a WAF is strongest when threats are detectable from traffic patterns and payload content. It is not designed to validate business rules such as object ownership or whether a user should be allowed to access a specific record inside an API.
Architecture
Architecturally, a WAF is deployed inline between external clients and the application or API it protects. It acts as a gatekeeper that all traffic must pass through before reaching any backend service. In most enterprise environments, the WAF is positioned at the edge of the application stack, either as a cloud based service, a reverse proxy, or a component integrated into load balancers, API management platforms, or WAAP solutions.
All incoming requests terminate at the WAF. If the connection is encrypted, the WAF decrypts the traffic so that it can inspect the full contents of the request. It then parses the HTTP protocol, extracts headers, query parameters, cookies, and body payloads, and evaluates them against a ruleset that defines what is allowed and what is considered malicious.
For traditional web applications, this inspection focuses on URLs, form fields, and cookies. For APIs, modern API aware WAFs go further by understanding structured data formats such as JSON, XML, and GraphQL. Instead of treating the body as an opaque text blob, the WAF parses individual fields, parameters, and nested objects so that security rules can be applied at a much finer level.
Many API WAF deployments are also connected to API specifications such as OpenAPI or learned schemas. This allows the WAF to enforce a positive security model where only expected endpoints, methods, and fields are allowed. Requests that include unknown parameters, incorrect data types, or unexpected structures can be blocked even if they do not match a known attack signature.
Once a request passes inspection, the WAF forwards it to the API gateway or directly to the backend service. On the response path, some WAFs also inspect outgoing data to detect or mask sensitive information, enforce response size limits, or prevent accidental data leakage.
This architecture gives the WAF strong control over what enters and leaves the application at the protocol and payload level. What it does not provide is visibility into how backend services interpret those requests, how they apply business rules, or whether the user is entitled to access the specific data being returned.
API Gateway vs WAF: Differences
API gateways and WAFs are often deployed together, which leads many organisations to assume that they provide overlapping or even interchangeable protection. In reality, they solve very different problems.
An API gateway is designed to manage how API traffic enters and flows through an application. A WAF is designed to inspect that traffic for malicious patterns and protocol level abuse. One is a traffic management and integration layer. The other is a perimeter security control. Neither is designed to understand how data is accessed, owned, or misused inside an API.
Example of API Gateway and WAF
Consider an e commerce platform that exposes APIs for user accounts, product catalogs, and order management. Customers use a mobile app to browse products, place orders, and view their purchase history. Partners use APIs to integrate logistics and payment services.
When a customer opens the mobile app and requests their order history, the request first goes to the API gateway. The gateway verifies the user’s authentication token, checks that the request is within allowed rate limits, and routes the request to the internal order service that handles /orders endpoints. From the gateway’s perspective, the request is valid because it is authenticated, within quota, and sent to the correct service.
Before that request reaches the order service, it passes through the WAF. The WAF inspects the URL, headers, and JSON body. It checks for injection attempts, malformed payloads, and protocol violations. If the request contains a suspicious pattern, such as SQL injection in a parameter, the WAF blocks it. If the request looks syntactically normal, it is forwarded to the backend.
Now consider what happens inside the order service. The API returns order data based on a user ID provided in the request. If the application fails to properly verify that the user owns the order ID being requested, an attacker could modify that parameter to retrieve someone else’s order history.
In this scenario, both the API gateway and the WAF did exactly what they were designed to do. The gateway authenticated and routed the request. The WAF confirmed that the payload was not malicious. Neither of them evaluated whether the user was entitled to see the specific order records being returned.
This is where many real world API breaches occur. The infrastructure layers are working, but the business logic and data access controls inside the API are flawed.
Types of vulnerabilities in API Gateway vs WAF
API gateways and WAFs address different classes of risk, and their blind spots are just as important as their strengths. Understanding what each layer can and cannot prevent explains why many API breaches occur even when both are deployed.
Vulnerabilities Relevant to an API Gateway
An API gateway is focused on traffic management and access control at the perimeter. When vulnerabilities exist at this layer, they usually relate to how requests are admitted and routed rather than what the application does with the data.
Common gateway related weaknesses include misconfigured authentication, overly permissive API keys, missing rate limits, and incorrect routing rules. If a gateway allows access to sensitive endpoints without proper token validation, or if it does not enforce meaningful quotas, attackers can abuse legitimate APIs to scrape data, brute force credentials, or overload backend services.
However, even when the gateway is perfectly configured, it does not validate whether a user should be allowed to access a specific object, record, or function inside an API. It assumes that once a request is authenticated and routed, the backend will enforce business rules correctly.
Vulnerabilities Relevant to a WAF
A WAF is designed to block malicious input and protocol level abuse. It is highly effective against injection attacks, malformed requests, and many automated scanning tools. For APIs, modern WAFs can also detect mass assignment, some forms of BOLA, and basic abuse patterns when schema enforcement and behavioral rules are in place.
Where WAFs struggle is in understanding application specific logic. They do not know how user roles, object ownership, pricing rules, or workflow states are supposed to behave inside the application. If an API allows a user to change an order status, view another customer’s record, or download sensitive data using a legitimate looking request, the WAF has no reliable way to determine whether that action is allowed.
The Shared Blind Spot
Most high impact API breaches exploit this gap between perimeter enforcement and application logic. Attacks such as Broken Object Level Authorization, privilege escalation, and excessive data exposure use valid credentials and well formed requests. They do not trigger WAF signatures. They do not violate gateway rules.
They exploit the fact that neither the API gateway nor the WAF understands how data should be accessed at the business level.
When to use which: API Gateway vs WAF
API gateways and WAFs are not alternatives to each other. They are built for different purposes and are most effective when used in the contexts they were designed for.
An API gateway should be used whenever an organisation needs to manage how APIs are exposed, consumed, and operated. It is essential for scenarios where multiple clients, partners, or internal teams access the same backend services. Gateways are the right tool for handling authentication, routing, versioning, traffic shaping, and integration across distributed systems. Without a gateway, enterprises struggle to maintain consistent access control, performance, and reliability as their API footprint grows.
A WAF should be used whenever an organisation needs to protect applications and APIs from malicious traffic and protocol level attacks. It is designed to block injection attempts, malformed requests, automated abuse, and many common exploitation techniques. For APIs that are exposed to the internet, a WAF provides an important defensive layer that reduces the risk of known attack classes reaching backend services.
The problem arises when these tools are treated as a complete API security strategy. An API gateway ensures that requests are routed and authenticated. A WAF ensures that requests look safe. Neither ensures that the request should be allowed to access the specific data or function being invoked.
Enterprises should deploy API gateways to manage access and scale. They should deploy WAFs to filter malicious traffic. But neither should be relied on to enforce business logic, object level authorization, or data access controls. Those risks exist deeper inside the API layer, where perimeter tools have limited visibility.
Challenges of using API Gateway and WAF and its solutions
API gateways and WAFs are essential parts of modern application architectures, but they were not designed to solve every API security problem. When organisations treat them as comprehensive protection, structural gaps appear that attackers routinely exploit.
One major challenge is limited visibility into business logic. API gateways know how to route requests and validate tokens. WAFs know how to inspect payloads and block known attack patterns. Neither understands whether a user is allowed to access a specific account, order, or record inside an API. This is why attacks such as Broken Object Level Authorization and privilege escalation continue to succeed even in well protected environments. The solution is to introduce controls that validate object ownership, role permissions, and data access rules based on how APIs actually behave, not just how requests look.
Another challenge is reliance on static rules and configurations. Gateways depend on routing and access policies. WAFs depend on signatures, schemas, and manually tuned rules. In fast moving environments where APIs change daily, these configurations quickly fall out of sync with reality. New endpoints appear, old ones are repurposed, and data models evolve, creating blind spots. The solution is continuous discovery and validation driven by runtime traffic so that security controls reflect what is actually deployed, not what is documented.
A third challenge is alert noise and false confidence. WAFs can generate large volumes of alerts based on pattern matching, many of which are not exploitable. Gateways generate operational metrics that say nothing about data misuse. Together, they can create the impression that everything is under control while real vulnerabilities remain undetected. The solution is to focus on exploitability and context, identifying only those issues that can actually be used to extract data, bypass authorization, or manipulate business workflows.
There is also a coverage gap for modern API architectures. APIs now span microservices, third party integrations, and AI driven components. Gateways and WAFs see only the traffic that passes through them. They do not see how data moves between internal services, how tokens are reused, or how sensitive fields propagate across systems. The solution is end to end visibility into API interactions and data flows across environments.
Used correctly, API gateways and WAFs remain valuable. Gateways provide control and reliability. WAFs reduce exposure to known attacks. But to secure APIs in practice, organisations must complement these tools with controls that understand runtime behavior, user context, and data access at the API layer.
Best Practices to follow for API Gateway and WAF
API gateways and WAFs are most effective when they are deployed as part of a layered, well governed API security strategy. Used in isolation or left poorly maintained, they provide only an illusion of protection.
One key best practice is to treat the API gateway as an access and traffic management layer, not a security boundary. Gateways should be used to enforce authentication, rate limits, and routing consistency, but they should not be relied on to enforce fine grained authorization or data ownership rules. Those controls must exist inside the API itself, where business logic and user context are available.
A second best practice is to keep gateway configurations tightly aligned with real API usage. Versioned endpoints, deprecated routes, and partner integrations should be actively reviewed and pruned. Stale routes and overly broad API keys are a common source of data leakage and abuse.
For WAFs, a critical best practice is to move beyond default rule sets. Generic signatures catch obvious attacks, but API traffic requires schema aware and context aware inspection. Where possible, WAFs should be connected to API specifications so that only expected endpoints, methods, and fields are allowed. This reduces both false positives and missed attacks.
Another best practice is to monitor for behavior, not just payloads. WAF logs should be reviewed for patterns such as ID enumeration, abnormal access sequences, or unusual data volumes. These signals often indicate exploitation even when individual requests look legitimate.
Finally, both gateways and WAFs should be continuously tested against real API abuse scenarios. Changes in code, integrations, and user flows introduce new risks that static configurations cannot anticipate. Regular validation of access control, data exposure, and business logic is necessary to ensure that these perimeter tools are not protecting a fundamentally vulnerable API.
How Levo offers runtime API Security
API gateways and WAFs control how requests enter a system and how they look at the perimeter. They do not control how APIs behave once a request reaches application logic, data stores, and downstream services. That gap is where most API breaches occur.
Levo is designed to close that gap by combining runtime visibility with continuous pre production and production security controls. It does this through a set of integrated API security modules that operate across discovery, documentation, testing, monitoring, detection, and protection.
Together, these modules allow enterprises to see every API, understand how it behaves, and validate security continuously rather than relying on static rules or periodic audits.
Levo continuously discovers every API that exists across internal, external, partner, and third party environments. This includes APIs that are not documented, no longer maintained, or created dynamically by modern development and AI driven workflows.
Each discovered API is mapped to its endpoint, method, authentication scheme, and owning service. This gives security and engineering teams a complete, always current view of the attack surface. Without this foundation, neither a WAF nor an API gateway can provide reliable protection because unknown APIs cannot be secured.
Levo automatically generates and updates API documentation based on real runtime traffic and code level signals. Instead of relying on manually maintained OpenAPI files that drift out of date, Levo produces accurate specifications that reflect how APIs actually behave in production.
This documentation includes endpoint definitions, parameters, authentication requirements, error codes, and data structures. It becomes the authoritative source for security testing, monitoring, and enforcement.
Levo identifies where sensitive and regulated data flows across APIs by inspecting live traffic and payloads. This allows enterprises to understand which endpoints process personal data, financial information, or other regulated fields.
With this visibility, teams can apply stricter controls to high risk APIs and prove compliance without relying on assumptions or incomplete inventories.
Levo uses runtime context to drive pre production and continuous API security testing. Instead of generic scanners that guess at inputs, Levo generates payloads based on real traffic, user roles, and data flows.
This allows it to test for vulnerabilities such as Broken Object Level Authorization, privilege escalation, injection flaws, and business logic abuse in a way that reflects how attackers actually exploit APIs. These tests run in CI/CD and on a schedule, supporting a shift left model that finds real vulnerabilities before they reach production.
Levo reports only vulnerabilities that are exploitable in the real environment. Each finding is backed by a reproducible request and mapped to the affected API, microservice, and owning team.
This eliminates the alert noise that plagues traditional tools and allows security and engineering teams to focus on issues that represent real risk.
Levo continuously monitors API behavior in production. It tracks how endpoints are used, how data moves between services, and how users and systems interact with APIs over time.
This makes it possible to detect changes in behavior, new exposures, and compliance drift as soon as they appear rather than after a breach or audit failure.
Levo detects attacks based on behavior and context, not just signatures. It identifies patterns such as data enumeration, role abuse, abnormal access sequences, and unusual data transfers that indicate exploitation even when requests look legitimate.
This allows enterprises to catch the types of API attacks that pass through WAFs and gateways unnoticed.
Levo enforces security at runtime by blocking or constraining malicious API behavior based on what is happening inside the system, not just what appears in the request. This allows it to stop real abuse such as object level data theft and privilege misuse without breaking legitimate traffic.
Levo provides a centralized control plane where security, engineering, and compliance teams can see all APIs, risks, and controls in one place. This ensures that API security is not fragmented across tools, teams, and spreadsheets.
The way ahead: Implementing API Security beyond WAF and API Gateway
API gateways and WAFs remain important components of modern application stacks. Gateways provide stability, routing, and access control. WAFs reduce exposure to known attack patterns and malformed requests. However, neither of these layers was designed to govern how data, users, and business logic interact inside APIs.
Modern API breaches rarely rely on malformed payloads or protocol violations. They exploit valid endpoints using valid credentials to extract data, escalate privileges, and abuse workflows. These attacks operate entirely within the rules that gateways and WAFs are built to enforce.
Securing APIs in this environment requires a shift in focus.
Enterprises must move from perimeter filtering to runtime governance. They must be able to see every API that exists, understand how it is used, know what data it processes, and validate how access is enforced across real user roles and business flows. This visibility must extend across development, testing, and production, because vulnerabilities introduced in code become exploits in runtime.
This is where shift left and runtime security converge.
Pre production testing must be driven by how APIs actually behave, not by static specifications or guessed payloads. Production monitoring must detect abuse based on user behavior and data movement, not just on request signatures. Enforcement must be able to block real exploitation without breaking legitimate traffic.
Enterprises that rely only on API gateways and WAFs will continue to face blind spots, delayed detection, and costly incidents. Those that adopt a runtime and shift left driven API security model gain something fundamentally different.
They gain control over their API surface, confidence in how data is accessed, and the ability to prove security rather than assume it.
With Levo.ai, API security testing becomes continuous, intelligent, and proactive, aligning seamlessly with the pace and demands of modern software delivery.
Achieve 100% API Security with Levo. Book your Demo today to implement API security seamlessly.
