I recently sat down with Tejpal Garwhal, Application Security and DevSecOps Leader, for a conversation debunking some of the most common API security myths. From zombie endpoints to the limits of WAFS and gateways, we covered what’s really happening on the ground; and what security teams need to do differently. Here’s a quick rundown of the key takeaways, but for the full picture, watch the full webinar.
Myth 1: “We Know What APIs We Have”
This was the first and most persistent myth we tackled. Most teams assume that if they’ve deployed APIs, they must know what exists in their environment. But the reality is very different.
Tejpal pointed out how API sprawl often happens without anyone noticing. Developers build and deploy endpoints on short timelines, documentation lags behind, and different teams might assume someone else is keeping track. In practice, no single group holds a full view of the API inventory.
Worse, many rely on API gateways or management platforms as their source of truth, but those tools only track what’s been routed through them. They won’t catch endpoints deployed ad hoc or legacy APIs left behind in codebases long forgotten.
We agreed: without complete visibility, securing APIs is guesswork.
Myth 2: “Our APIs Don’t Expose Sensitive Data”
Often, Tejpal and I hear that encryption solves the data exposure problem. As long as you’re using HTTPS, the assumption goes, everything’s safe. However, as we discussed, encryption in transit or at rest doesn’t address who can access the data or how it’s exposed through business logic.
Tejpal highlighted how developers often over-share by default. Without strict design boundaries, APIs tend to return full data objects rather than minimal fields. Couple that with poor access control or logging that includes sensitive details, and you have a silent liability.
In one example we discussed, an organization believed they were secure because its web UI had strong controls. Behind the scenes, however, the underlying APIs still allowed unauthenticated access. It’s a common disconnect. APIs don’t need to be visible to be vulnerable.
Myth 3: “Our WAF and Gateway Cover API Security”
We’ve both seen this myth cause problems. It’s based on a misunderstanding of what traditional tools actually do.
A WAF, for example, can detect basic injection attacks, but it often struggles with API protocols like GraphQL and gRPC, or when requests are deeply nested or batched. Similarly, API gateways can manage authentication and routing, but they aren’t designed to parse and inspect request logic or flag business abuse.
In short, these tools serve important functions, but weren’t built to detect the kinds of threats we now routinely see in API traffic, like Broken Object Level Authorization (BOLA), zombie endpoints, or agent-triggered scraping. Ultimately, relying on WAFs and gateways alone creates a dangerous false sense of coverage.
Myth 4: “Detection is the Same as Prevention”
This is where our conversation turned toward operations. Detection is essential, but it’s not enough. Simply knowing about an attack doesn’t reduce risk; blocking it does. And alerts without action are just noise.
Tejpal emphasized how many organizations have tools that generate impressive-looking reports but lack the workflows or coverage to intervene at the moment of attack. By the time a detection is triaged, the damage might already be done.
We talked about the need for real-time blocking, not just alerting. Especially considering automated bots and AI agents are probing APIs at scale, modern defenders can’t afford to just react; they have to prevent.
Myth 5: “Security Testing Tools Are Enough”
While testing plays an important role, it’s only one part of a broader lifecycle. You can’t scan your way to a secure deployment.
We both agreed that security needs to shift left. Organizations need to incorporate threat modelling into design and validate security contracts before APIs go live. But we also stressed a concept that often gets overlooked: shielding right. Even if you build secure APIs, attackers don’t stop trying. You need runtime protection that adapts to what’s happening now.
What Modern API Security Actually Requires
So, that begs the question: what does API security actually require? We’ve debunked the myths, now it’s time to reveal the truths. Here are six foundational principles that Tejpal and I think every organization should anchor their API security program on:
- Full Discovery: Know all your APIs, not just the ones in the gateway
- Data-Centric Risk Modeling: Understand what each endpoint exposes and who should access it
- Behavioral Detection: Spot abuse based on how APIs are used, not just known signatures
- Real-Time Blocking: Alerting is too late if attackers are already inside
- Scalability and Context: Defenses must operate at the speed of DevOps and understand semantic context, especially in AI-driven environments
- Business Alignment: Secure the APIs that tie directly to revenue or critical operations first.
One point that stuck with us was the idea that many API security strategies still operate as technical exercises, isolated from the business. But if an API powers payment, inventory, or customer data, it is the business. Security decisions must reflect that fact.
However, this blog just scratches the surface of our conversation. If any of this resonates, I encourage you to watch the full conversation. We cover real-world breaches, demo examples of overlooked risk, and walk through a modern strategy that aligns Dev, Sec, and Ops around a shared threat model. Watch the webinar here.
Source link
