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.
Originally published at The New Stack
FAQ update to this post
Is WAAP enough for API security?
No. WAAP is an important layer of defence, but it is not a complete API security programme. WAAP platforms are primarily designed to inspect production traffic and block known web attacks, malicious bots, volumetric abuse and suspicious request patterns. Some also provide API discovery and basic schema validation, but their protection is usually applied after an API has been developed and deployed.
42Crunch addresses risks earlier and more deterministically by using the OpenAPI or GraphQL contract as the security source of truth. It audits the contract for security weaknesses, tests whether the running API conforms to it, enforces Security Quality Gates in CI/CD and applies contract-specific runtime protection to both requests and responses. This helps prevent insecure APIs from reaching production rather than relying solely on detecting attacks after exposure.
What are API-specific risks that WAAP alone may not address?
BOLA (Broken Object-Level Authorization): An authenticated customer changes /accounts/123 to /accounts/124 and receives another customer’s information. The request is correctly formed and may look entirely legitimate to a WAAP. Contract-driven testing can exercise identifiers and identify whether object-level controls are consistently enforced.
BFLA (Broken Function-Level Authorization): A normal user calls a valid administrative operation such as DELETE /users/456. The request contains no malware or injection payload; the vulnerability is that the backend fails to enforce the required role.
BOPLA (Broken Object Property-Level Authorization): An API accepts an undocumented property such as “isAdmin”: true, or returns sensitive fields including internal risk scores or personal data. Generic request inspection may not know which properties are permitted for that operation or user. 42Crunch validates inbound and outbound traffic against the approved schema.
Excessive data exposure: A mobile application needs a customer’s name and delivery status, but the API response also includes date of birth, account identifiers and internal notes. The response is valid JSON and not intrinsically malicious. the 42Crunch API positive security model will reject response content that is not defined in the contract.
Contract drift and shadow operations: A developer deploys a new endpoint, parameter or response field without updating or approving the API definition. A WAAP may simply learn this as normal traffic. 42Crunch Drift Scan compares the deployed API with the approved contract and reports discrepancies. Learn more about 42Crunch API Scan types.
Weak or incomplete API definitions: Required authentication may be missing from an operation, input strings may have no length or pattern constraints, and response schemas may be loosely defined. These design weaknesses exist before runtime traffic is available. 42Crunch audits the API contract for definition quality, authentication, authorization and schema security prior to deployment. Learn more here 42Crunch API Security Audit
Unrestricted access to sensitive business flows: An attacker automates valid operations to hoard inventory, create thousands of accounts, scrape pricing or repeatedly redeem a promotion. Each request may be technically valid, so conventional attack signatures may not identify the underlying business abuse.
Unrestricted resource consumption: An API permits oversized uploads, excessive pagination or computationally expensive operations that increase cloud costs or exhaust backend resources. OWASP notes that API resource abuse can cause both denial of service and significant operating-cost increases. OWASP API4: Unrestricted Resource Consumption
Improper API inventory management: Deprecated versions, debug endpoints and forgotten APIs can remain exposed without current documentation or security controls. Traffic protection does not by itself establish whether an API is approved, current or governed.
Unsafe consumption of third-party APIs: An application trusts data returned by an external API and processes it without adequate validation. The dangerous content may enter through an outbound dependency rather than a hostile client request. This is recognized as a distinct API risk in the OWASP API Security Top 10.
