“DAST is dead”—that’s the phrase that appears every year on social media and in cybersecurity newsletters. But what if in 2024, it finally came true?

DAST, Dynamic Application Security Testing (even though we see a new terminology “Dynamic API Security Testing” popping up here and there within the last weeks), has been a cornerstone of application security testing in the last decade but it’s time to make way for the next generation of application security testing – Business Logic Security Testing.

Why is understanding business logic security issues becoming increasingly crucial for security engineers? In this article, I decided to explain the reasons behind this growing importance.

“As security folks, we'll probably stop focusing on the foundational issues. And we'd be looking at much more difficult issues that our tooling has a hard time to find. Like business logic issues… “ – Jeevan Singh, Director of Security at Rippling

The security in the SDLC: the "shift-left" trend

In an agile setting, developers update their applications (or backends, services… whatever they call them!) continuously, in my own team sometimes even daily. The traditional approach to conducting penetration tests once or twice a year doesn’t make any sense anymore as a new vulnerability can be introduced at each build. The outdated nature of manual penetration tests became quite evident to me a couple of years ago (hence one of the reasons why I decided to build Escape). This is why the “Shift-left” trend started to surge, and the security solutions on the market have to adapt.

The initial benefits of DAST tools were clear – it was the only solution that could detect vulnerabilities in a running application (it sees how the application behaves in its environment). On the other hand, Software Composition Analysis (SCA) tools primarily focused on listing known vulnerabilities within dependencies rather than assessing the business logic of the application. This limitation narrowed their scope in identifying potential risks within the application's core functionalities.

And a lot of times people tend to overly focus on the left side of the SDLC and not enough on the right-hand side of the SDLC. And you can see it in the vendors. 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. So, and a lot of times folks just tend to say, let's put SAST in place, let's put all the security guardrails on the left-hand side and not worry about the right-hand side. – Aleksandr Krasnov, principal security engineer at Meta

Static Application Security Testing (SAST) tools, while useful, often produced an overwhelming number of false positives and false negatives due to their inability to assess applications in their operational state. This discrepancy between the static analysis and the actual runtime behavior of the application hindered SAST tools' effectiveness in pinpointing genuine vulnerabilities.

Interactive Application Security Testing (IAST) tools occupied a middle ground, offering insights into application vulnerabilities while the application was running, thereby enhancing accuracy compared to SAST tools. However, IAST implementations are complex and introduce performance overhead during testing since the tool is actively monitoring and analyzing the application's behavior.

Runtime Application Self-Protection (RASP) tools faced a different challenge as they lacked the ability to generate traffic. Consequently, they could only identify vulnerabilities after an attack had already compromised the application and its infrastructure, rendering them less proactive in threat mitigation compared to DAST tools.

Thus, DAST came at the perfect timing: just after the build, when the code is fresh & running. It can seamlessly integrate into a CI/CD pipeline, or a dev/prod environment a few seconds after the release before it’s too late. As black-box testing, it does not need to access the code nor the traffic.

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

Disclaimer: In this part, I’m not even going to cover Generalist DAST like Rapid7, Qualys, or Nessus that are NOT testing the application layer but just the network layer; I’m going to focus on DAST for testing APIs.

1. DAST brute force requests do not pass the data validation layer

While DAST is theoretically the only solution with perfect timing and the most efficient "shift-left" security solution, it comes with its own set of issues:

Current DAST solutions are inadequate; they generate requests that make no sense. They employ brute-force fuzzing. In the best-case scenario, they take schemas (like the OpenAPI Specification for REST APIs) as input to send data of the proper type. However, just because a field labeled email is tagged as a string does not mean that sending a nonsensical string such as r4d0omFu!1=1 to an email field is logical. Consequently, requests in DAST do not pass the data validation layer, thus they are stuck without testing anything.

This is the main problem with very traditional solutions like OWASP ZAP (now ZAP). Today, the most prominent API DAST vendors are merely wrapping OWASP ZAP: StackHawk, Checkmarkx, Gitlab, Traceable, etc. OWASP ZAP and third-party services. In practice, as proven by our Escape vs ZAP comparison (coming soon in a separate article), roughly 0% of the application resolvers are covered by OWASP ZAP and its wrappers from a business logic POV, rendering them as ineffective as Rapid7, Qualys, and Nessus for testing APIs.

2. DAST is dumb and does not automatically perform Business Logic Security Testing

As highlighted by Marina Polishuk from Microsoft (her paper "REST-ler: Automatic Intelligent REST API Fuzzing" is the first paper to seriously detail this problem), DAST is unable to generate and execute legitimate sequences of requests that align with the business logic of the API. For example, DAST cannot adequately test the specific endpoint GET /user/{id} because it does not comprehend that the {id} should originate from a user it has either created or encountered previously. Consequently, no complex attack scenarios can be tested in this case. Again, OWASP ZAP has completely failed in this regard.

Some tools, like Nuclei or bChecks, can assist with API business logic, but not automatically! Indeed, these solutions are more suited to assess the app's surface automatically using simple fingerprint techniques or complex business logic manually (using hardcoded checks). Most recent solutions, such as Akto, for example, are merely wrappers of open-source tools like Nuclei.

Especially, Nuclei and bChecks require manual maintenance of your tests. This approach does not align well with a security context: since applications are updated daily, should the checks also be updated and maintained daily? Who is responsible for implementing and maintaining security tests within an organization? Properly assessing the security of an app and its business logic would necessitate assessing thousands of scenarios for hundreds of different security vulnerabilities. This would require writing and maintaining an infinite number of manual checks for each API every day at each update, adapting to new use cases of your APIs, staying informed of new API security vulnerabilities daily in order to support new vulnerabilities, implementing, and adapting the checks, etc., which is unrealistic.

3. If DAST claims to assess the business logic, it requires your organization's data

Some solutions claim to be able to assess the business logic of APIs. However, to do so, they require an agent* in your production environment that captures all the traffic and replay requests using your organization’s private data.

Solutions that affirm to “remediate API vulnerabilities by integrating with the existing security infrastructure and blocking attacks in real-time, all without deploying agents or requiring network modifications” 1) do require an agent and 2) do not perform business logic testing but runtime protection.

Then they require access to customers' data in production – it’s intrusive, it’s overly complex and dangerous for privacy reasons.

If you think about it: the goal of testing an app with each deployment is to focus especially on the new features of the app. In this context, it does not make any sense to use traffic as these new features have not been yet exposed to any traffic. 

4. No DAST really supports GraphQL and other modern APIs

GraphQL is really specific. All DAST solutions on the market claiming to support GraphQL actually treat GraphQL as OWASP ZAP treats REST APIs.

This means that no solution tries to send sequences of requests that make sense according to the business logic of the underlying API. Especially in GraphQL, the requests sent by those solutions do not take into account the Graph-specific features like deep queries, recursive queries, aliasing, batching, fragments, etc., ()  nor the numerous access control issues implied by its Graph nature. 

Other API types like gRPC, Websockets, etc. also have their own specificities, and no DAST solution on the market has been built to test the business logic of these API types in depth.

The essential shift to business logic security testing

In conclusion, the era of DAST tools as we know them for API security testing is drawing to a close. As highlighted throughout this article, the limitations of DAST in effectively addressing modern application vulnerabilities, particularly those rooted in business logic, have become increasingly apparent.

While DAST tools have served their purpose in the past, their inability to autonomously generate meaningful traffic aligned with API business logic underscores the need for a more advanced approach.

Escape's proprietary business logic security testing algorithm, rooted in Feedback-Driven Semantic API Exploration (FDSAE) principles, paves the way for this next generation of security testing methodologies. By autonomously generating legitimate traffic tailored to the specific nuances of each API, Escape's solution empowers security professionals to effectively navigate the challenges and complexities of modern applications. You can learn more about our algorithm in this article.

As companies continue to prioritize security in their development processes, Business Logic Security Testing will undoubtedly take center stage to keep APIs secure and we're here for it 😉

*** This is a Security Bloggers Network syndicated blog from Escape - The API Security Blog authored by Antoine Carossio. Read the original post at: https://escape.tech/blog/dast-is-dead-why-business-logic-security-testing-takes-center-stage/