Application Security Tools Are Not up to the Job of API Security
The last two decades have seen a proliferation of software (according to GitHub there has been a 35% increase in code repositories in 2020 alone) into every aspect of our lives in the form of web or mobile applications. Adversaries have increasingly attacked these applications, and defenders have adopted various testing tools and technologies to protect them.
Today most enterprises have in place an Application Security (AppSec) program to manage the deployment of these tools and manage associated vulnerabilities. The only constant in the world of software development is change, and never more so than in recent years with the widespread adoption of cloud native technologies (such as containers, orchestration platforms) and the breakdown of the monolith via microservice adoption.
Unfortunately for AppSec teams, this rapidly evolving landscape has meant that much of the tooling they use is not up to the task of securing their applications.
Nowhere is this more apparent than with the security of application program interfaces (APIs) which are foundational to all modern applications. APIs present a unique challenge from a security perspective because of their uniqueness from an attack point of view — a fact recognized by OWASP who produced a dedicated Top 10 list for API security vulnerabilities.
Why Existing AppSec Tools Fare Badly on APIs
SAST wasn’t designed for API-centric applications
The workhorse of any AppSec program is the Static Application Security Testing (SAST) which is a “white box” assessment of the vulnerabilities in an application derived by examining the source code and creating a model of the data flow through an application to determine where an application may be vulnerable to external attack by, for example, injection attacks.
Complex data flow paths or unsupported frameworks reduce the accuracy of a SAST analysis since the model may be incomplete or inaccurate.
In the case of APIs, this is significantly more complex since most SAST tools are designed to work with web applications constructed as for example Java Servlet PHttpRequest.Bodyages or .Net ASP pages.
In this case, the SAST tool detects instances of HttpRequest.Body within a codebase, since this is typically how a webpage is constructed. Unfortunately, APIs are significantly more complex since they are constructed differently using a myriad of 3rd party frameworks (such as SpringBoot, Flask, etc), and the detection of the entry points into the application is more complex leading to inaccurate models and higher rates of false negatives.
DAST Lacks Context of APIs
Dynamic Application Security Testing (DAST) is a “black box” assessment of a running application by exercising the application endpoints in the same way a user — or attacker — would. DAST tools are adept at “spidering” a web application to determine the page structure and input fields and then to attack these fields to identify vulnerabilities.
Unfortunately, for an API the DAST scanner is unable to enumerate the API endpoints making such attacks impossible. Some DAST tools (such as OWASP ZAP) can ingest an OpenAPI/Swagger file to seed the spidering process.
Even in this case without a deeper understanding of the API endpoints, DAST tools can’t provide an intelligent assessment of API security. For example, a DAST scanner will not be able to identify Broken Object Level Authorization (BOLA) issues unless it has an awareness of the parameter value used to identify the object (in order to fuzz this field) and then to be able to interpret the response to determine whether the attack succeeded, or if any error is returned.
Shifting Left on API Security
Security tools have shown great advances in the past decade however, the most significant impediment to highly scaled and effective AppSec initiatives is that the security activities are conducted too late in the Software Development Lifecycle (SDLC).
Testing too late increases the cost of remediation and reduces the likelihood of developer remediation. In the case of typical monolithic applications, there was no alternative but to test late in the cycle since a functional, running instance of the application was required to perform testing, particularly for DAST.
With the advent of a microservice-based API-centric architecture, it is possible to test each of the individual APIs as they are developed rather than requiring a complete instance of an application — enabling a “shift left” approach allowing early testing of individual components.
Because APIs are specified earliest in the SDLC and have a defined contract (via an OpenAPI / Swagger specification) they are ideally suited to a preemptive “shift left” security testing approach — the API specification and underlying implementation can be tested in a developer IDE as a standalone activity.
Core to this approach is API-specific test tooling as contextual awareness of the API contract is required. The existing SAST/DAST tools will be largely unsuitable in this application — in the discussion on DAST testing to detect BOLA we identified the inability of the DAST tool to understand the API behavior.
By specifying the API behavior with a contract the correct behavior can be enforced and verified enabling a positive security model (desired behavior is whitelisted) as opposed to a black list approach such as DAST.
The diagram below summarizes key differences between API security native testing versus DAST testing, from 42Crunch:
Source: 42Crunch.
The security testing tools I’ve discussed are typically operated by an organization’s security or AppSec teams and often imposed on developers who may find them unsuitable to modern development practices such as continuous integration (CI) and continuous deployment (CD) — sometimes leading to developer frustration and lower adoption rates of security tooling.
In contrast, API security tooling that can add value to the development effort (for instance allowing continuous validation of API specifications) within their environments is more likely to be adopted and actively used.
Conclusion
Do the more traditional security testing tools such as SAST and DAST have a place in your API development environment? The answer is almost certainly yes, particularly if you have an existing investment and process centered on these tools. By leveraging the declarative nature of API specifications, a savvy organization can use API-specific tooling to take a hard “shift left” approach and enforce and test API security using a positive security model. Any resultant APIs produced are then guaranteed secure by design, providing a solid foundation for the high layer application stack (webpages or mobile applications) which can be tested using SAST/DAST tools.