AppSec Tools NonSync With API Security
Share this:
Softwares kept decorating day to day life of humans in any one form of mobile or web platforms. Attackers have increasingly exploiting these applications, and defenders have adopted various testing tools and technologies to protect them.
Application Security is in place in most of the organization to manage the deployment of these tools and manage associated vulnerabilities. Change is the only form that keeps constantly evolving around softwares even with cloud native applications.This rapidly evolving landscape has meant that much of the tooling they use is not up to the task of securing their applications.
API 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
SAST Non Sync with API-centric applications
The SAST 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. But complex data flow paths reduces the accuracy of a SAST analysis since the model may be incomplete or inaccurate.
Unfortunately, APIs are significantly more complex since they are constructed differently using a myriad of 3rd party frameworks and the detection of the entry points into the application is more complex leading to inaccurate models and higher rates of false negatives.
DAST & APIs Context Upside Down
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 adapt 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 can ingest an OpenAPI/Swagger file to seed the spidering process. DAST tools can’t provide an intelligent assessment of API security.
Focus shift on API Security
The 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 developer remediation. 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, for DAST.
With 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 an approach allowing early testing of individual components. Enable to test it as a standalone IDC in earlier phase of development, API specific tooling required. Doing so correct behaviour can be enforced enabling a positive security model
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.
Final Thoughts
Leveraging the declarative nature of API specifications, organization can use API-specific tooling to 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 which can be tested using SAST/DAST tools.
