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.<\/p>\n
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 \u2014 a fact recognized by OWASP who produced a dedicated\u00a0Top 10 list for API security vulnerabilities<\/span><\/a>.\u00a0<\/span><\/p>\n <\/p>\n The workhorse of any AppSec program is the Static Application Security Testing (SAST) which is a \u201cwhite box\u201d 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.<\/p>\n Complex data flow paths or unsupported frameworks reduce the accuracy of a SAST analysis since the model may be incomplete or inaccurate.\u00a0<\/span><\/p>\n 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.<\/p>\n In this case, the SAST tool detects instances of\u00a0 Dynamic Application Security Testing (DAST) is a \u201cblack box\u201d assessment of a running application by exercising the application endpoints in the same way a user \u2014 or attacker \u2014 would. DAST tools are adept at \u201cspidering\u201d a web application to determine the page structure and input fields and then to attack these fields to identify vulnerabilities.\u00a0<\/span><\/p>\n Unfortunately, for an API the DAST scanner is unable to enumerate the API endpoints making such attacks impossible. Some DAST tools (such as\u00a0OWASP ZAP<\/span><\/a>) can ingest an OpenAPI\/Swagger file to seed the spidering process.<\/p>\n Even in this case without a deeper understanding of the API endpoints, DAST tools can\u2019t provide an intelligent assessment of API security. For example, a DAST scanner will not be able to identify Broken Object Level Authorization (BOLA<\/span><\/a>) 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.<\/p>\n Security tools<\/a>\u00a0have 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).<\/p>\n 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.<\/p>\n 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 \u2014 enabling a \u201cshift left\u201d approach allowing early testing of individual components.\u00a0<\/span><\/p>\n 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 \u201cshift left\u201d security testing approach \u2014 the API specification and underlying implementation can be tested in a developer IDE as a standalone activity.<\/p>\n 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 \u2014 in the discussion on DAST testing to detect BOLA we identified the inability of the DAST tool to understand the API behavior.<\/p>\n 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.\u00a0<\/span><\/p>\nWhy Existing AppSec Tools Fare Badly on APIs<\/strong><\/h2>\n
SAST wasn\u2019t designed for API-centric applications<\/h3>\n
HttpRequest.Body<\/code>\u00a0within 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.<\/p>\n<\/h3>\n
DAST Lacks Context of APIs<\/h3>\n
<\/h3>\n
Shifting Left on API Security<\/h3>\n
![\"\"](\"https:\/\/staging2022.42crunch.com\/wp-content\/uploads\/2021\/10\/8551cf3c-crunch.png\")
<\/p>\n