Why runtime testing is critical for API security

The scale of what falls on the runtime side of that line is significant. 43% of newly added CISA Known Exploited Vulnerabilities in 2025 were API-related, the majority involving runtime behavior that static analysis has no mechanism to verify. Key among those gaps is broken object-level authorization (BOLA), which has consistently been the #1 OWASP API Security Top 10 security risk since 2019 – and BOLA cannot be confirmed without runtime testing using two live authenticated sessions and a real database. 

This article explains what the main API-relevant vulnerability classes are, why they require runtime observation to confirm, and why API DAST is the validation layer that closes the gap.

Runtime API security testing is the practice of evaluating API security by interacting with the API in its deployed, running state – sending real requests, observing real responses, and testing actual application behavior under real configuration. Unlike static analysis, which examines source code before execution, runtime testing validates what the API actually does when accessed: authorization enforcement, authentication flows, error handling, deployment configuration, and business logic that only manifest in a live application.

The five classes of API vulnerabilities that only runtime testing can confirm

The following five vulnerability classes share a common property: they cannot be fully confirmed without observing runtime behavior in a deployed application. Static analysis can identify code patterns that suggest a risk may exist, but it cannot verify whether the risk is real – because the evidence exists only in the running system. This makes authenticated runtime API testing a non-negotiable part of application security.

1. Authorization failures: BOLA and BFLA

Consider a straightforward scenario: a user calls GET /api/orders/1042. The API queries the database and returns the order. The code is syntactically correct, but it results in vulnerable behavior: it returns the order to any authenticated user, not just the one who placed it. Change the ID to 1043 and you could have someone else’s data.

That is BOLA. It has held the top spot in the OWASP API Security Top 10 since 2019 and accounts for a large proportion of API breaches. Broken function-level authorization (BFLA), where users can invoke functions or access endpoints reserved for other roles, is the second-ranked risk. Combined, BOLA and BFLA are the most prevalent root cause of API incidents.

Why static analysis can’t verify BOLA and BFLA

SAST can identify a database query pattern. What it cannot determine is whether that query constitutes a BOLA vulnerability, because doing so requires knowing:

• Which objects the application’s data model designates as user-owned
• What authentication context exists at the time of the query
• Whether the same endpoint returns different results for different authenticated users

Authorization logic may look correct in code and still fail in the running application. A caching layer returning stale pre-authorization responses, a middleware misconfiguration, or an ORM escape path can each introduce BOLA in the deployed system from code that passes static review. SAST has no visibility into any of these interactions.

The same limitation applies to authentication state. Modern APIs depend on token refresh cycles, distributed identity providers, and session state that spans multiple services. Code review can confirm that an authorization check exists. It cannot confirm that the check behaves correctly under real OAuth flows, across service boundaries, or after a token refresh invalidates a cached session.

How runtime testing confirms BOLA and BFLA

DAST with multi-user testing can detect BOLA in APIs using the following flow:

• Authenticate as User A
• Capture User A’s object identifiers from real API responses
• Authenticate as User B
• Check whether User B’s session can access User A’s objects – if it can, BOLA is confirmed, with the HTTP request and response as proof

BFLA testing follows a similar pattern across roles rather than users: does a standard account gain access to administrative functions when tested directly, bypassing the frontend controls that ordinarily hide them?

2. Deployment and gateway misconfigurations

59% of disclosed API breaches in 2025 required no authentication. The exploited APIs were simply accessible without credentials – not because attackers bypassed authentication, but because authentication was never enforced in the first place.

Picture a modern API deployment: an ingress controller routes external traffic, an API gateway enforces authentication policies, a reverse proxy handles TLS termination, and the application sits behind all of it. A misconfigured routing rule in the ingress controller can expose an internal endpoint directly. A gateway policy that applies authentication to /api/v2/ but not /api/v2/internal/ leaves an entire path unenforced. The application code is untouched, the specification is accurate – but the deployed system is wide open.

Why SAST can’t verify runtime misconfigurations

Source code does not contain deployment configuration. An ingress rule, a gateway policy, a Kubernetes NetworkPolicy, a cloud load balancer rule – none of these have any representation in the application repository. SAST has no visibility into the environment in which code runs, and therefore no ability to verify whether the authentication and authorization the code assumes are being correctly enforced upstream.

How runtime testing confirms runtime misconfigurations

Runtime DAST sends unauthenticated requests to every discovered endpoint and confirms whether the response is a correctly rejected request (401 or 403) or an incorrectly returned payload. The test asks a simple question: does the deployed system behave as the specification requires when called without credentials? That question has no answer until a real request reaches the real infrastructure.

3. Business logic flaws

In 2022, a security researcher discovered that Coinbase’s Advanced Trading API would accept a trade that sold cryptocurrency using a different asset’s balance – effectively buying with funds that weren’t being debited. The requests were valid, the credentials were real, the API call followed normal trading workflow. The flaw was in the business logic: the system validated each step in isolation but did not enforce consistent balance constraints across the transaction. Business logic abuse accounts for a significant chunk of advanced API attacks, and the pattern is consistent: legitimate traffic, legitimate credentials, a sequence the application wasn’t designed to handle.

Other common variants of business logic abuse:

• A rate limit that applies per session but not per account, allowing an attacker to open multiple sessions and bypass throttling entirely
• A checkout flow where the payment step can be skipped by calling the order confirmation endpoint directly
• A coupon that can be applied multiple times because redemption state isn’t validated server-side

Why SAST can’t verify business logic vulnerabilities

Similar to auth issues, a business logic flaw isn’t a function call or an import – it’s a combination of operations in a specific sequence and with specific state that produces an unintended outcome. SAST pattern matching cannot model multi-step workflow interactions or the combinatorial space of API call sequences that expose business logic flaws. Even AI-enhanced SAST that understands semantic code meaning still cannot simulate those workflows against a live database and real session state.

How runtime testing confirms business logic vulnerabilities

Stateful API DAST maintains session context across requests and probes out-of-sequence calls, boundary conditions, and workflow bypass attempts – testing whether the application enforces the intended process, not just whether each individual request is valid. A scanner that tests one request at a time will pass every step and miss the flaw entirely.

4. Third-party and integration runtime behavior

Modern APIs rarely operate as isolated services. They delegate authentication to identity providers, enforce policies through API gateways, cache responses through shared layers, coordinate state through message queues, and call out to third-party services for data enrichment, payment processing, and authorization decisions. The security behavior of the complete system emerges from all of these interactions together – and none of it is predictable from source code analysis of any single component.

A third-party identity provider that changed its token validation behavior. An API gateway caching authorization decisions and returning stale responses after a permission change. A service mesh policy that was updated in production but not in staging, meaning tests passed on an environment that no longer matches deployment. These aren’t hypothetical edge cases. They are the category of vulnerability that surfaces between release cycles, after code has been reviewed and approved.

Why SAST can’t verify runtime dependency behavior

Third-party API behavior, infrastructure component behavior, and emergent properties of multi-component systems have no representation in source code. A caching anomaly, an identity provider behavior change, or a service mesh misconfiguration exists only in the running system.

How runtime testing confirms runtime dependency behavior

Runtime DAST probes the complete deployed system from the outside in. A caching layer returning stale authorization responses produces observable responses that differ from what correct behavior would generate – and a runtime scanner observing those responses can detect the discrepancy. Source code analysis never sees those runtime responses.

5. Blind injection and out-of-band vulnerability classes

Some vulnerabilities can be exploited without leaving any trace in the HTTP response the scanner observes. Examples include:

• Blind SQL injection that exfiltrates data via DNS
• Server-side request forgery (SSRF) that causes the server to make outbound requests to internal infrastructure
• Stored cross-site scripting (XSS) that executes in an admin context hours after the payload was injected

From the perspective of the scanning session, all of these look like normal requests that returned normal responses.

Why SAST can only flag the potential risk

SAST can identify code patterns that suggest one of these vulnerabilities may exist – a string concatenated into a SQL query, a user-supplied URL passed to an HTTP fetch. What it cannot do is confirm exploitability. Confirmation requires runtime evidence: the database returned data through the injection channel; the server made an outbound DNS request to attacker-controlled infrastructure.

How runtime testing with an out-of-band capability helps

Runtime DAST tools that only inspect in-band HTTP responses share the SAST blind spot. When the evidence of exploitation exists only out of band – as a DNS callback or an HTTP request to an external server – in-band inspection produces nothing to observe. Reliable detection requires a dedicated out-of-band capability.

Invicti’s API DAST extends runtime testing to also cover this class. When a blind SSRF payload, an out-of-band SQLi payload, or a blind XSS payload executes, the Invicti OOB service receives the outbound callback and confirms the finding with a timestamp and a reference to the originating scan – evidence rather than inference.

What runtime testing validates that static analysis cannot

The table below maps the coverage boundary between SAST and runtime DAST, using Invicti’s API DAST as the capability baseline. The point is not that one approach is inherently better – it is that they cover fundamentally different vulnerability classes. Leaving either out leaves some categories of risk uncovered.

Organizations that treat API DAST as optional because they have SAST are not saving effort – they are leaving BOLA, BFLA, business logic flaws, deployment misconfigurations, and blind injection classes unverified. On the other hand, organizations with DAST but no SAST may miss hardcoded secrets, vulnerable dependencies, and code-level patterns that static analysis finds efficiently before deployment.

A mature API security program needs both – not because the coverage overlaps, but because the vulnerability landscape divides across two distinct capability boundaries.

Why the AI era is making runtime testing more critical, not less

There is a credible argument in current AppSec discourse that AI-powered SAST is improving fast enough to reduce the need for runtime testing. It deserves a direct response.

AI-enhanced static analysis is genuinely improving. AI code assistants identify security patterns in real time, understand semantic context that traditional SAST misses, and measurably accelerate remediation. These are real improvements to a real capability.

But they improve detection of code-level security flaws – the class that SAST could always address, but handled too slowly or inaccurately. They do not change the fundamental boundary of what static analysis can verify. Better pattern matching does not produce visibility into runtime behavior, deployment configuration, multi-user session dynamics, or the enforcement behavior of the live system. Those require a running application – and no amount of improved code analysis changes that.

The AI era also amplifies the need for runtime testing for a reason that often goes unacknowledged: AI-assisted development produces APIs faster than security review can keep pace with. When a developer reviews AI-generated code, the question is typically “Does this do what I intend?” – not “Does this correctly enforce per-object authorization across all authenticated user roles, against every object type the data model designates as user-owned, through all the caching and middleware layers sitting between the request and the database?” The authorization flaws AI-generated code most commonly introduces are exactly the BOLA and BFLA class that only runtime testing can confirm.

The Wallarm 2026 API ThreatStats Report reinforces this: 36% of all AI vulnerabilities identified in 2025 qualify as API vulnerabilities, and that overlap holds steady in exploited vulnerabilities. As AI-driven systems multiply the APIs in production, the surface that only runtime testing can cover grows with them.

Runtime DAST is not a legacy practice being superseded by better static analysis. It is the layer that verifies what actually runs – and that responsibility is expanding, not shrinking.

How Invicti delivers runtime API security testing

Invicti’s API security testing is built around confirming findings wherever automated validation is possible. The platform doesn’t just observe runtime behavior – it validates whether vulnerabilities are actually exploitable, using proof-based scanning to generate evidence that eliminates false positives before findings reach the team.

Multi-user authorization testing

Invicti authenticates with multiple test accounts at different privilege levels and tests cross-user authorization for every endpoint accepting object identifiers. BOLA is confirmed by capturing User A’s object identifiers from real API responses and verifying whether a different authenticated session can access them. BFLA is tested by comparing accessible functions and resources across privilege levels. Every confirmed finding includes the HTTP request and response demonstrating unauthorized access.

Stateful workflow analysis

Invicti maintains session state across multi-step API interactions, testing business logic flaws through workflow manipulation, out-of-sequence calls, and boundary conditions that only manifest across a sequence of requests. This is what separates runtime validation from endpoint-by-endpoint scanning: the ability to test whether the application enforces the intended process, not just whether individual requests are handled correctly.

Deployment configuration testing

Invicti tests every discovered endpoint without authentication and with varying authentication scope, confirming whether the live system enforces what the specification requires – regardless of what the source code says. Configuration gaps that exist nowhere in the repository are visible the moment a real unauthenticated request reaches the deployed infrastructure.

Out-of-band detection

For blind injection classes that produce no in-band HTTP evidence, Invicti OOB confirms exploitation through DNS and HTTP callbacks. Blind SSRF, out-of-band SQLi, and blind XSS are confirmed with timestamped evidence linked to the originating scan, extending coverage to the vulnerability classes that in-band scanning cannot reach.

Complete API surface coverage

Invicti discovers APIs through DAST crawling, OpenAPI and Swagger import, source code repository mining, and network traffic analysis in containerized environments – before testing begins. Runtime validation covers the full surface, including undocumented and shadow endpoints that would otherwise be tested by no one.

The limitations of simpler DAST scanners – limited discovery, weak authentication handling, no out-of-band capability – are real. The answer is not to reduce reliance on runtime testing. It is to use runtime testing that closes those gaps.

Conclusion: Validate what your static analysis cannot see

Modern AppSec isn’t a choice between SAST and DAST, especially when it comes to API security. The key requirement today is using runtime evidence to determine which findings represent real, exploitable risk – and prioritizing remediation accordingly. SAST identifies what the code suggests might be vulnerable. Runtime DAST confirms what the running application actually exposes.

The authorization failures, misconfigurations, business logic flaws, and blind injection vulnerabilities that drive the majority of API breaches are not visible in source code. Invicti’s proof-based API DAST confirms each finding with exploit evidence, so your team focuses on verified risk rather than investigating theoretical ones.

Next steps

• Learn how to build API security into CI/CD pipelines
• See how automated API discovery methods can fill gaps in your API inventory for security scanning
• Request a demo to see Invicti’s API DAST in action in your environments