Reinventing API security: Why Escape is better than traditional DAST tools

Is the current approach to API security really the best path forward? We don’t think so. In addition to traditional traffic-based tools, many security teams have relied on DAST tools (more often than not to check the DAST box), overlooking the real pain points faced by security and development teams, as well as the critical synergies between them.

DAST approach overlooked the fact that API development has not been centralized in the enterprise, and most security teams do not know how many APIs they have to secure, where those are deployed, and their business criticality. This leads to slow API security adoption, partial coverage, and difficulty estimating the investment needed to secure all APIs for most organizations.

Given that breaches often speed up most security actions (unfortunately), there’s no longer any excuse for outdated technologies that do not have automated API discovery, 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. We strongly agree that developers should be your allies.

At Escape, we’re committed to challenging the limitations of traditional DAST tools that aim to solve problems for application security engineers. We've got you! Dive into this article to discover how.

Classical approaches and how they failed to deliver on their promises

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. 

We have previously discussed why securing APIs amid this proliferation is critical and how the rise of API security companies reflects the industry's response. In this article, we will focus on companies that have integrated API security within their Dynamic Application Security Testing (DAST) approaches.

As we mentioned, the first API Security companies approached API Security through DAST (Dynamic Application Security Testing).

Companies like 42Crunch, Stackhawk, and Bright built API-centric DAST solutions for use in pre-production and development environments. These solutions detect API security vulnerabilities early in the development process and fix them before production. 

However, despite innovative ideas (IDE Plugin for 42Crunch, Developer-friendliness for Stackhawk, and in-house testing engine for Bright), those solutions had significant drawbacks and failed to gain wide adoption.

DAST has a bad reputation, and it’s well-deserved.

So the DAST tools usually tend to be very inefficient and they tend to not produce anything that is useful neither for the organization nor for security engineers. - Aleksandr Krasnov, Principal Security Engineer at Meta

Challenges in setting up scans and maintaining API documentation

The first major drawback of the DAST approach is the amount of configuration required to make it work. To assess the security of an API, those solutions need the API documentation in the form of an OpenAPI Specification or a Swagger file.

Very often, some back-and-forth between development and security teams is necessary to get this documentation. Even more frequently, this documentation doesn’t exist at all.

Visibility gaps

The second drawback is that most companies lack a precise understanding of which development teams are exposing APIs.

They also often lack the capability to quickly deploy an automated API discovery solution that continuously operates and connects the risk owner to the exposed APIs.

Given that enterprise companies expose thousands of APIs online, such a solution struggles to scale, as it requires accurately identifying the developers of each API and obtaining the necessary API documentation from them.

Lack of support for modern technologies and business logic understanding

Traditional DAST tools like Rapid7 or Qualys DAST struggle with the complexities of modern applications, including microservices and GraphQL APIs. They often focus on surface-level vulnerabilities without scanning the deeper business logic of GraphQL APIs, leading to missed critical vulnerabilities and an inability to adapt to dynamic, multi-layered architectures.

Companies leveraging GraphQL for their APIs often face numerous security challenges. Traditional API security tools cannot adequately support GraphQL's complex queries and data-fetching capabilities, leaving APIs vulnerable to attacks.

It's hard to actually fix highly critical vulnerabilities

You can't fix everything at once. You need to understand what's critical and what can wait.

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, including on our podcast.

When I express concerns about my day-to-day job, it's mainly about wanting more effective ways to prioritize tasks. The common issue is wasting time having developers fix things that were never actually vulnerable, necessitating better false positive categorization. This should be the priority - James Berthoty, founder of Latio.tech, ex-security engineer at Pager Duty

Many organizations report that their security teams are overwhelmed with false positives from traditional API security tools.

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.

Even when issues are communicated clearly, developers often face problems they may not know how to resolve quickly.

Try to figure out how you make the DAST tool work for you and for the developers in a way that it's succinct. Nobody needs to know the generic explanation of like, here's your XSS, and here's like five paragraphs to read about it. Engineers want to see, you know, you have cross-site scripting for this parameter. - Aleksandr Krasnov, Principal Security Engineer at Meta

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. 

Easy configuration and real-time scan accuracy

Not all APIs have an available specification, and even when they do, ensuring its validity can be challenging. We also recognize that manually authoring a specification is not a task most developers enjoy. However, having one is crucial for providing more context to the API service and its schema. That's why we've integrated automated specification generation into Escape.

Our automated schema generation ensures that DAST scan configurations are always up-to-date as your APIs evolve or new endpoints are added. This keeps your DAST scans accurate without manual intervention.

And this not only saves time and effort for both security and development teams but also enables development teams to redirect their focus towards higher-value tasks. With the burden of manual specification creation lifted, they can now dedicate their time to more impactful activities. Meanwhile, security teams are empowered to dedicate increased attention to analyzing scan results, rather than being tied up with manual scan configurations.

Discover business-critical vulnerabilities even in GraphQL

Escape natively supports GraphQL, addressing its specific security challenges - including their propensity to injections, DoS and brute-force attacks.

“Escape is an innovative tool, and its results and algorithms are truly impressive. It was able to find GraphQL vulnerabilities that their competitors haven't seen. It also provides me with extensive testing capabilities." - Pierre Charbel, Product Security Engineer, Lightspeed

Our platform’s advanced algorithms handle GraphQL’s unique features, such as deep queries and access control issues, ensuring comprehensive security coverage and seamless integration with modern API technologies. We make sure to test your GraphQL endpoints to ensure a maximum security for your platform.

Fix what matters

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.

More than that, we also allow users to set up specific notification rules tailored to their unique security needs. This means that alerts can be fine-tuned to ensure that only relevant and high-priority notifications are sent, reducing the noise and improving response times. This customization ensures that security teams can stay focused on critical issues without being distracted by minor or false alerts.

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.

"Escape - is the only security scanner for GraphQL that is engine aware and developer friendly."
Aleksandr Krasnov, Principal Security Engineer at Meta; ex-Staff Security Engineer, Thinkific

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.

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
• We benchmarked DAST products, and this is what we learned
• Top Dynamic Application Security Testing (DAST) Tools for 2025
• Escape vs Rapid7
• Escape vs Invicti