Bridging the API Security Gap – The Perception and Reality of API Security

A recent report from Akamai as covered in the apisecurity.io newsletter, corroborates earlier findings from a report we commissioned of EMA Enterprise Management Associates into enterprise adoption patterns of API security technologies. Both studies indicate that while there is a broad recognition and understanding by management of the need for API security, there is a mistaken belief by CISOs that their existing tools are effective at protecting their APIs. Sadly, this “API security gap” is real, as evidenced by the rising volume of successful API breaches, further driven by the adoption of AI and LLMs which is predicted to fuel at least 30% growth in demand for APIs by 2026.

“95% believe their existing security tools are effective at protecting their APIs and believe that the solution purchased will safeguard their organization.” EMA

“92% of APAC executives said their organizations experienced an API incident in the past 12 months, but only 37% of all respondents could confirm that they know which APIs expose sensitive data” Akamai

Why is there an API Security Gap?

So why is there such a disconnect between the perception CISOs hold about how secure their APIs are, and the actual reality? A major reason is the belief—highlighted by Forrester—that API discovery and behavior monitoring tools alone provide complete API security. This leads to a false sense of confidence. The confusion is compounded by a lot of market noise, especially around recent acquisitions that have bundled these tools with traditional application security or WAF platforms, making it harder to understand what’s actually being protected.

The real problem often begins after the initial rollout of API security tools. This is typically when executives feel they’ve addressed the risk—yet it’s also when the most dangerous gaps emerge. That’s because these tools create a false impression that API security is “done,” when in reality, the process has only just begun. Let’s look at some of the “gaps” these tools create due to the unique nature of APIs.

Lack of Contextual Awareness

Traditional application security solutions are not designed to understand the unique behavior and data flows of APIs. Most API attacks—such as those involving Broken Object Level Authorization (BOLA), rate limiting bypass, business logic abuse, and mass assignment—rely on manipulating legitimate-looking requests in ways that evade generic security checks.

• • WAFs operate at the network or HTTP level and often treat API requests as regular web traffic, missing subtle but dangerous variations in payloads or access patterns.
  • SAST tools, while useful during development, typically lack visibility into runtime behaviors and the dynamic nature of API interactions.
  • DAST tools often fail to fully exercise API functionality, particularly when APIs are undocumented, versioned, or require complex authentication.

Without a deep understanding of the API’s purpose, data structures, and access control logic, these tools cannot reliably detect or block targeted API attacks.

No Runtime Enforcement Capability

Even modern API behavior monitoring tools often operate in passive or detection-only mode. While they can observe traffic and flag anomalies, they’re typically not configured to actively block threats. 

• • Anomaly detection relies on traffic monitoring to inventory APIs, requiring costly cloud traffic mirroring and full integration with all relevant networked devices. Missed or unsupported devices create security blind spots, while low-traffic APIs remain undiscovered.
  • The fear of false positives and disruption to legitimate traffic means most organizations run these tools in alerting mode only.
  • Although they can integrate with enforcement layers like WAFs or API gateways, the handoff is often manual or delayed, reducing their real-time protection value.
    

As a result, malicious requests can still reach backend systems, even when anomalies are detected—leaving a critical window of exposure.

Absence of a Secure-by-Design Approach

Many API security programs fail because they treat security as a layer applied after development and event deployment, rather than embedded throughout the API lifecycle. As security is a critical requirement, it is better to address API security requirements from the initial design phase rather than trying to shoehorn in security after the API is deployed. Studies recently indicated that rework of software builds, including security-related fixes, often accounts for 20–40% of all effort on software projects, with medium-sized businesses losing around $4.7 million annually due to these inefficiencies.

• • Perimeter-focused tools cannot compensate for insecure code, poor design choices, or misconfigured APIs.
  • Without integrating API security testing tools into developer IDEs, API design tools, and CI/CD pipelines, organizations miss the opportunity to catch and remediate vulnerabilities before APIs reach production.
  • Anomaly detection tools depend on monitoring network traffic to identify APIs, which requires costly cloud traffic mirroring and full integration with all networked devices. Missed or unsupported devices create significant blind spots. 

A true secure-by-design approach means shifting security left—making it a core part of how APIs are built, tested, and deployed. 

Bridging the API Security Gap

The gap between perception and reality in API security isn’t just a matter of oversight—it’s a systemic issue rooted in misplaced confidence, fragmented tooling, and a lack of context-aware protection. To close this gap, organizations must shift from reactive, perimeter-focused thinking to a continuous, lifecycle-oriented approach to API security. 

That means going beyond discovery and monitoring, and instead embedding security from the first line of code all the way through to runtime protection. Secure-by-design practices, developer-integrated tools, and intelligent runtime enforcement are not optional—they are essential. Organizations that recognize this—and act accordingly—will be far better positioned to defend against the growing wave of sophisticated API threats. Those that don’t will remain vulnerable, falsely reassured by tools that were never built to protect what APIs expose.

42Crunch is the only API security platform providing the automated API security testing and real time blocking capabilities to enable companies achieve full end-to-end API security.