Reinventing API security: Why Escape is better than traditional traffic-based tools

Is the current approach to API security really the best path forward? We don’t think so. Over the past few years, many API security solutions have relied on traditional traffic-based methods that overlook the real pain points faced by security and development teams, as well as the critical synergies between them.

As we move through 2024, the exponential growth of APIs presents new challenges. According to recent Gartner’s market guide, APIs — especially shadow and dormant ones — are causing data breaches among organizations that, on average, exceed the magnitude of other breaches. 

Given that breaches often prompt most security actions (unfortunately), there’s no longer any excuse for outdated technologies that can’t discover APIs outside of an API gateway, WAF, or a proxy, or that fail to provide security teams with actionable insights to collaborate effectively with development teams. After all, security is as much about relationships as it is about technology.

At Escape, we’re committed to challenging the limitations of traditional traffic-based tools and addressing the challenge of building an accurate API inventory in a world where rapid deployment is crucial for business survival. Dive into this article to discover how we’re tackling these issues.

Why securing APIs is critical for all organizations

Since the development of Mobile and Single-Page Applications (SPAs), APIs have become the main way for organizations to expose data on the web.

Organizations also understood that by exposing public APIs, they could empower external developers to build on top of their services, thus driving usage of their platform and even creating new revenue streams by monetizing external API calls.

Today, APIs are used by all enterprise companies and governments. They allow easy and seamless exchange of data with providers, customers, partners, and even the state. This growing usage skyrocketed API traffic on the internet, and in 2023 a typical enterprise site saw an average of 1.5 billion API calls.

For every person and company connected to the internet, sensitive data is flowing through through hundreds, if not thousands, of APIs. Since APIs handle sensitive data and are directly exposed to the internet, they are a target of choice for hackers. Since 2022, 190M sensitive data records have been breached. In our latest research, we estimate that Enterprise companies lost $31B due to breaches.

Organizations are now realising they can’t get rid of their APIs, nor slow down the development of new APIs due to how critical it has become for their business and their revenue. Yet, they can’t let the API sprawl uncontrolled and unsecured due to the sensitive nature of data transmitted and the potential damage the breach of a single API could cause. 

Many people in the security industry understood this and started building API Security companies. In this article, we'll focus on API security companies that use a network-monitoring approach. Traceable AI, Noname Security, and SALT Security have adopted this strategy.

How traditional traffic-based API security solutions fail to deliver on their promises

Using integrations with API Gateways, reverse proxies, and WAFs, network-monitoring API security solutions analyze live API traffic and detect or even attempt to block attacks in real time. 

This approach has several advantages: having API documentation is not required, as they have access to the real API traffic data. By blocking attacks directly in production, they reduce the amount of work needed by developers to fix API vulnerabilities.

This approach was seductive and received a lot of Venture Capital funding in the past years: $150M for Noname Security with its recent acquisition by Akamai, $200M for Salt Security. 

Despite this, it failed to gain widespread adoption. It seemed that every deployment of API security tools was slow and painful, and even recruiting armies of sales wasn’t successful at skyrocketing the growth of those API Security companies.

So what happened? 

As seductive as network-based API protection is, there are also significant drawbacks to this approach.

It takes weeks to get accurate visibility 

You can’t secure what you can’t see - that is the motto Escape lives by. 

Network API security solutions, however, often struggle with the initial step of discovering your APIs. They often require installing agents or monitoring traffic, which can be intrusive and resource-intensive. They are also difficult to integrate and don't offer visibility outside of API gateways, WAFs, or proxies.

Ease of deployment is crucial for an efficient API security solution:

1. Complex and lengthy deployment processes can leave APIs exposed, increasing the risk of breaches.
2. Simplified deployment processes minimize the need for specialized knowledge and extensive internal resources, which allows organizations’ security teams to focus on continuous monitoring and improvement rather than prolonged setups.
3. Since developers frequently build and update APIs, a security solution that integrates seamlessly with a rapid development lifecycle is essential for scaling security measures effectively across a large number of APIs.

Ultimately, the biggest drawback of those solutions is that they can only secure the environment in which they are deeply and manually deployed. This is achievable for a limited number of critical APIs. However, for large-scale organizations with multiple business units, thousands of developers, and dozens of thousands of APIs deployed in a decentralized manner in hybrid, multi-cloud environments, it is barely achievable.

Most of the enterprise teams we interviewed didn’t manage to deploy those solutions to more than a fraction of their APIs, sometimes even after years of usage. 

Significant privacy concerns are still at stake

More than that, API protection solutions need large-scale, unrestricted access to their customers' sensitive data to observe API traffic.

Even if technical solutions are developed to mitigate this, such as processing API traffic analysis within the customer's environment, it remains a significant privacy concern for many organizations. In traditional, traffic-based API Security solutions it is difficult for the buyer to hide sensitive information from them unless you want incomplete coverage of your APIs.

Such deployment difficulties can lead to incomplete coverage and leave many APIs unprotected. Many organizations find it challenging to deploy traditional API security solutions across all their environments, which leads them to look for easier solutions.

False positive rates are high

Many organizations report that their security teams are overwhelmed with false positives from traditional API security tools. This leads to alert fatigue, and eventually, critical security incidents may be missed.

When in blocking mode, traffic-based solutions risk creating false positives and blocking legitimate users, ultimately causing a Denial of Service.

Also, even if the request is not blocked, the time required to analyze the traffic creates a delay that impacts the API’s overall performance, which is unsuitable for many traffic-intensive applications.

For this reason, most of their users do not activate the blocking mode and rely on purely monitoring malicious traffic.

Prioritization often does not exist

Traditional API security solutions often fail to provide comprehensive vulnerability management, leaving many weaknesses undetected. While traditional AppSec tools can detect most of the vulnerabilities present in a software, this doesn’t make them “comprehensive”. 

Alert fatigue is a major problem in 2024 across different levels of organizations. It surfaced in almost every conversation we had with Application Security practitioners on our podcast, and in a recent Cycode survey, 85% of CISOs said their software and development teams had a strained relationship because of alert fatigue and vulnerability noise.

Security companies need to show some results and value during PoCs in hopes of a sale. Because of this, most security tools were built, so that they always find results, no matter how critical. 

This led to a significant amount of noise among security tools results. Security teams have learned how to navigate the noise and configure those tools, but development teams, who have become security stakeholders more recently, haven’t. 

Consequently, many developers are unhappy with security product’s results and complain heavily when they feel they are assigned the task of fixing a false positive. It threatens the relationship between developers and security teams, and ultimately, the developer’s buy-in for security practices.

Losing developers’ buy-in for security is one of the main fears we heard from security professionals because most security teams’ mission is to empower safe development practices, not fight with developers to block them from deploying software updates.

“The main challenge is prioritizing vulnerabilities for developers from different tools.” - Head of Application Security in a public financial corporation (UK)

As many AppSec practitioners mention, the real challenge in API security today isn't just about detecting vulnerabilities—though that's undeniably important. It's about prioritizing these vulnerabilities in a meaningful, strategic way.

The key isn't to display every flaw but to highlight the most critical ones, so you can act upon them and prevent API breaches.

Security breaches frequently expose significant gaps in vulnerability management practices, allowing attackers to exploit known weaknesses.

For example, the 2022 Optus data breach revealed significant gaps in the company's vulnerability management practices since the lack of comprehensive vulnerability scanning allowed attackers to exploit known weaknesses, resulting in a major data breach.

Network-based solutions are not built with developers in mind

Network monitoring tools often struggle to integrate with modern DevSecOps practices. They typically only protect APIs after they have been deployed and do not integrate smoothly with CI/CD pipelines.

You have a bunch of different vendors that will tell you, you know, here's all the issues with it and they'll give you like paragraphs over paragraphs and paragraphs of generic description of like, here's your SQL injection. Here's how it maps to OWASP Top 10 and developers will just skip it. They'll be like, I don't care about it. What do I need to fix? You know, so just make it more understandable, make it more actionable to developers, and make it short because nobody got time. - Aleksandr Krasnov, Principal Security Engineer at Meta

Sometimes, it's just too late to have vulnerabilities in production environments.

This poor integration into development cycles is compounded by the fact that many traditional tools fail to provide actionable remediation for developers. It's just plain frustrating for development teams and slows down the secure development lifecycle.

“It is important to emphasize actionable remediation because most tools lack this.” - Ex-CISO in financial sector. 

Developers are thus often left dealing with issues they may not know how to resolve quickly.

Without clear, actionable steps, developers may implement temporary or incorrect fixes, increasing the problem and creating additional work somewhere down the line.

A new approach to API security: How Escape does it better

API Security has consistently been one of the top 3 concerns of all Enterprise security teams we interviewed in the past year. However, their personal experience or discussions with their peers made them doubtful that current API Security solutions could fit their needs.

Out of our discussions and a lot of care toward understanding security practitioners’ needs, we created a whole new approach to API Security that is based on three main pillars:

1. Security teams can’t secure what they don’t know they have, we need to start by showing them what they have
2. Relationship with the developers is key, we need to help avoid developers' unnecessary fixes by prioritizing issues and providing them with actionable fixes
3. Security teams’ time is precious, and the solution with the best time-to-value wins

Start by showing security teams what they have. In minutes.

Both API Security Testing and API Runtime Protection solutions are based on the premise that the security team knows where to deploy API Security in the first place. In most enterprise companies, this is not the case.

This encourages security teams to secure first the environments they know about, which might not be the most critical ones or even not be a significant part of their total attack surface, leaving many gaps.

We can’t emphasize how blind this strategy is in an enterprise context. No good security can come out of a bad understanding of the threat model and the attack surface. Putting patches before identifying the leaks is a very bad use of any security team’s budget.

This is why we advocate for an API Security approach that starts by providing security teams with an accurate view of what they have to secure, which means

• What are the exposed APIs?
• What’s their business use? How critical are they to the business?
• Which are internal and external?
• Who uses them? External users? Internal developers? Partners? 
• How do they authenticate users?
• What sensitive data do they handle?

At Escape, we leverage a unique combination of subdomain enumeration, AI-powered fingerprinting, and OSINT techniques to discover and catalog all exposed APIs with minimal input—just a domain name.

Escape scans domains, frontend websites, and SPAs to find all API routes. Then, it connects to code repositories, API gateways, and development tools to enrich this data, creating a thorough and continuous inventory of exposed endpoints and the sensitivity of the data they handle.

This agentless discovery process provided a comprehensive and continuously updated inventory. 

Using the techniques discussed above, Escape uncovers both documented and undocumented APIs, including APIs outside of API gateways, WAFs, or proxies. This process requires no manual configuration, significantly reducing the time and effort needed to identify the organization’s vulnerable APIs.

Once discovered, APIs are automatically classified by business use, data sensitivity, and risk level. This helps organizations prioritize their security efforts on the most critical APIs, ensuring that resources are allocated effectively to protect sensitive data.

Only after having this accurate API Inventory can teams start wondering about the right security controls to implement and where to implement them. You probably will not have the same strategies for critical, external-facing APIs handling sensitive data as for APIs serving only publicly available information. 

Focusing on what matters has never been easier

To us, any API Security program must have in place an efficient way for a security team to prioritise fixes and issues assigned to developers. Security teams must have the means to strip the noise from engineering teams, and only ask them to intervene for issues that are critical, urgent, and fixable.

An efficient way to prioritise issue is with context:

• Is this vulnerability critical and exploitable? 
• Is it exposed to the internet? Is it accessible to unauthenticated users or do you need a privileged account? 
• Does it affect sensitive data or critical services? 

Escape’s prioritization funnel focuses on ensuring that security teams can effectively manage and address the most critical vulnerabilities first.

Escape evaluates each vulnerability's potential impact on the business and its likelihood of exploitation. This process allows security teams to concentrate their efforts on the issues that pose the greatest risk to the organization.

Make developers your allies

After prioritization, if developers are asked to intervene and fix security issues, they must have all the information needed to take action, including the problem, consequences, code project and owners, responsible lines of code, and suggestions for remediation code.

If possible, this information must be in a tool that they use, either in their ticketing system or directly in their code repository. 

Developers are not security experts. Not yet.

To bridge this gap, Escape provides custom-generated remediations with code snippets tailored to the development team's specific technology stack.

"Actual future is the implementation of the tool that can automate the remediation, so that security engineer has to spend time rather on more strategic oversight, and code snippets are sent directly to engineers when vulnerability is found" - Product Security Engineer at pleo.io

This helps developers fix issues faster and more efficiently without needing deep security expertise. By providing clear, actionable steps and code examples, Escape ensures that vulnerabilities are not only identified but also effectively resolved.

Escape integrates seamlessly with development tools. It ensures that security measures are continuously updated in line with API changes, reducing the risk of vulnerabilities. Security testing is incorporated directly into CI/CD processes, with automated notifications and remediation suggestions provided to developers in their existing tools. This integration promotes a secure and efficient development environment, pushing security to the left.

Security teams’ time is precious: the best time-to-value wins

As a hybrid team between engineers and application security professionals, Escape’s team is not satisfied by how hard and slow most current security tools are to be deployed in enterprise environments. 

Any tool that requires updating production code or intercepting production traffic likely requires buy-in from several teams. For instance, deploying a Docker image and mirroring traffic will require the DevOps or Architecture team to intervene, the app’s production team to intervene, and the DPO team to verify how the data will be used.

It is painful to do this for a few applications. It is impossible to do this for thousands of applications from multiple teams in an enterprise context.

We strongly believe that the security community is increasingly unlikely to tolerate slow and complex deployments that require them to fight internal corporate politics.

Any new API Security approach should take this into account and focus on time-to-value, scalability, and diminishing maintenance efforts.

Conclusion

It’s been almost 4 years since we started Escape with a strong conviction that something was wrong in API Security despite how important it is and how important it will be as API usage grows.

Creating a solution and building an experience that tackles those challenges is hard and requires starting from scratch.

What do we need to achieve this:

1. Security teams can’t secure what they don’t know they have, we need to start by showing them what they have
2. Relationship with the developers is key, we need to help avoid developers' unnecessary fixes by prioritizing issues
3. Security teams’ time is precious, and the solution with the best time-to-value wins

"Organizations adopting a proactive approach to API security will experience 40% fewer successful API attacks than their peers" - Gartner Market Guide for API Protection, 2024

💡Want to learn more? Discover the following articles

• DAST is dead, why Business Logic Security Testing takes center stage
• Limitations of current automatic specification generation tools
• We benchmarked DAST products, and this is what we learned