Buchi Reddy B
CEO and Founder at Levo
.svg)
Having led engineering teams at growing startups, I understand the pressure of persistent feature requests. Feature requests are signs of product stickiness but they come at a cost: intensified development cycles with little space for in-depth testing.
While functional and performance testing usually gets the go-ahead, security testing must be addressed due to its manual nature. A recent Postman survey highlighted this, finding that only 37% of respondents prioritized security.
The result?
Vulnerabilities, including zero-day threats, slipping into production.
For many, adding Static Application Security Testing (SAST) to the CI/CD pipeline seems a logical step to secure code without slowing development.
After all, SAST is tailored for source code analysis and offers better coverage than Dynamic Application Security Testing (DAST) and Interactive Application Security Testing (IAST) without being in line or needing access to traffic.
Many may consider this a win-win solution. However, much more is required to secure cloud-native and microservices applications.
Read along to understand why this reliance on SAST as the sole pre-production security tool is dangerously insufficient.
Even though SAST is adept at detecting many common security vulnerabilities (CVEs), such as SQL injection, input validation, and stack buffer overflows, it has always had its cons.
The foremost of them is an overwhelming volume of flagged vulnerabilities, high false positives and false negatives, and limited framework support.
While Next-gen SAST solutions address some of these limitations, they still fail to deliver what modern applications need.
DevOps has not only changed the pace of software deployment but also altered the very composition of software.
Modern applications average between 26 and 50 APIs, each with its permissions, payload requirements, and user interactions.
The Postman survey reveals that 74% of respondents are API-first. APIs offer higher agility and resilience, with 63% of developers producing an API within a week and most API failures resolved within an hour.
Unlike web applications, the most dangerous API vulnerabilities exploit the sequential nature of API calls to bypass security measures or escalate privileges.
These applications often involve multiple API calls that interact in specific sequences, each dependent on the previous one. Detecting such vulnerabilities requires simulating such interactions in pre-production through dynamic and custom payload generation.
Since SAST tools only scan code and do not generate or observe it in runtime, they don’t completely address the runtime aspects of modern applications.
Go through the sections below to understand why SAST may identify vulnerabilities within individual API endpoints but cannot detect most of the OWASP API Security Top 10 vulnerabilities.
One of the critical requirements for effective API security testing is visibility—knowing what to test.
In typical web applications, the attack surface is clear; SAST tools know where the inputs are and how they might be exploited. SAST tools work well in this setting, where static code can be analyzed for vulnerabilities based on these known inputs.
However, APIs operate differently: instead of a UI, APIs exchange machine-to-machine requests whose contents are often only visible when executed with precise parameters during runtime.
SAST scans source code at rest without executing it, which means it misses API calls that are dynamically constructed, hidden behind middleware, or undocumented entirely (up to 80% of your API Ecosystem).
This leads to deploying insecure applications with a significant portion of the attack surface untested.
But even for the API endpoints that SAST does manage to identify, it fails at the most fundamental purpose of API security—safeguarding sensitive customer data.
Sensitive data flows, including how information is logged, cached, or transmitted, are only fully visible during runtime. Because SAST is fundamentally a static analysis tool, it cannot examine data flows across your API Ecosystem.
If SAST cannot even see how data moves across APIs how can it possibly secure it?
Static Application Security Testing (SAST) is effective at flagging insecure coding practices—such as hardcoded credentials—by analyzing individual code paths. However, SAST operates in isolation and does not capture how sensitive data flows during runtime across APIs, microservices, and third-party integrations.
Consider an example of a financial API endpoint that validates a user’s credit score. SAST cannot detect and thus stop data exfiltration since it fails to do anything besides flag insecure coding practices.
Some argue that SAST tools can be enhanced by manually feeding them API specifications, such as OpenAPI/Swagger files.
Even with API specifications, SAST cannot effectively address runtime vulnerabilities like Broken Object Level Authorization (BOLA) or sensitive data exposure:
This year, 40% of security vulnerabilities experienced by enterprises in production were due to broken, missing, or weak authentication.
With 57% of surveyed enterprises processing over 10 million API requests per month, scaling authentication efforts to this magnitude is challenging and prone to oversights.
Testing for authentication is necessary to prevent bypassed authentication, compromised credentials, and unauthorized access to sensitive data. However, SAST tools cannot test for the dynamic Authentication schemes and lack thereof easily.
SAST may flag weak forms of authentication, like basic or digest access, but APIs typically use stateless, token-based authentication that requires real-time testing.
Authentication schemes like OAuth 2.0 involve dynamic token generation, renewal, and expiration processes that SAST tools cannot simulate.
For example, if a token intended for a single session is reused across multiple sessions due to a flaw, it could lead to significant security breaches.
But since SAST is not looking at the runtime and token information, it would leave such, and many other AuthN misconfigurations undetected.
Strong authentication alone is not sufficient to protect APIs.
94% of API exploits happen against authenticated APIs.
Broken object-level authorization (BOLA), broken object property level authorization, and broken function-level authorization are critical issues that arise when APIs expose direct object references, such as user IDs or account numbers, without enforcing proper access control mechanisms dynamically.
Detection of these vulnerabilities requires continuous, context-sensitive evaluation of user permissions and data access that extends beyond what static analysis can deliver.
Although SAST might parse a function with exposed object references like user IDs, it lacks the contextual awareness to simulate an actual API request and verify that access control is properly enforced on a user-by-user basis.
For example, consider an API endpoint that returns user profiles based on the user_id parameter.
A SAST tool might parse the structure of this function, identifying database queries and return statements.
However, it cannot simulate an actual request scenario where a user tries to access another user’s data. It does not understand what user_id represents in terms of access control or verify that the user_id in the API request belongs to the authenticated user making the request.
The malicious user could loop through possible user_id values, accessing and exfiltrating sensitive information from various user accounts.
As seen above, the true cost of API insecurities lies in sensitive data exposure. APIs frequently handle personally identifiable information (PII), financial data, and healthcare information—data that must be meticulously protected to comply with regulations and maintain user trust.
A single API-induced data breach can result in millions in fines, litigation costs, and irreparable damage to customer trust.
To avoid these repercussions, your testing efforts must ensure that all potential avenues for unauthorized access to sensitive data are thoroughly tested and remediated.
However, relying solely on SAST and shift-left strategies is insufficient because such testing requires replication of code execution.
While integrating DAST testing might seem like a natural next step to address these gaps, unfortunately, DAST scanners cannot effectively test APIs either since they lack automatic and dynamic management of authentication token generation and renewals.
This is precisely why we built Levo. ai—to combine the best qualities of both SAST and DAST, offering a comprehensive understanding of applications along with dynamic payload testing, without the associated downsides like high false positives or lengthy scan times.
Book a demo through this link to see this in action!
.png){kind=logo}
.svg)
.svg)
.png)
.png)