APIs have moved beyond their old role as app-to-app integration plumbing. Customer applications and partner platforms increasingly depend on APIs, as do data products and AI services. Static analysis can check the code behind these endpoints, but it can’t tell you how they behave once they’re live, taking real traffic, and calling other services in turn.
That gap is why dynamic application security testing, or DAST, has had to extend its reach. Today, an increasing share of API activity takes place behind interfaces that never appear on a public website, so scanning the codebase or crawling web pages alone won’t surface them.
The numbers show how central and diverse APIs have become. One recent benchmark report found that 65% of organizations generate revenue from their API programs, while 46% expect to invest more in APIs over the year to come. As that investment grows, so does the amount of runtime surface that security testing needs to cover.
That security coverage is where the challenge starts, because it’s partly a visibility problem. A company may know which APIs it has published, but the deployed environment can still include old versions, mobile-only routes, and endpoints left behind by previous releases. That visibility problem gets harder once you look at how a single request actually gets fulfilled, rarely staying within the confines of one service. Microservices compound the issue, as each service boundary adds its own identity and its own path through a single transaction, and any one of them can go untested if it isn’t accounted for.
This is the environment DAST has to work in. Working within it properly means examining the application while it’s running, and that takes more than a target URL. The scanner needs an accurate view of the application and enough context to act as different users, clients, and services. Without that context, important parts of the system may remain untouched.
Mapping APIs Beyond the Browser
DAST tools begin by identifying where requests can go. Crawling remains useful for browser-facing applications, but APIs often reveal little through links and forms. Discovery has to come from somewhere else, and the most direct source is a document that already describes the API’s shape.
An OpenAPI document describes the API’s available routes and the structure of the requests each one accepts. Written in structured YAML or JSON rather than prose, the file is the source that tools can read to generate a documentation page a developer would actually browse. Because the format is machine-readable, a scanner can parse it directly rather than requiring a person to translate the API’s behavior into test cases by hand.
OpenAPI isn’t the only input a scanner can work from, though. Saved request examples from development or QA can provide working baselines, while proxy traffic may reveal routes used by mobile apps or internal services. These are sources that a written specification wouldn’t capture on its own.
Discovery can also test the accuracy of the organization’s inventory. An old version may still answer queries even though it no longer appears in the documentation. A service intended for internal traffic may be reachable through an overlooked route. Dynamic testing can assess those paths only when the scanner knows they exist.
Turning Valid Requests Into Security Tests
Random malformed traffic usually produces noise. A scanner learns more by starting with a legitimate request and changing one element at a time.
It might add a property the normal client never sends, try an HTTP method outside the documented workflow, or push a field past its expected length or type. The OWASP Web Security Testing Guide’s API testing overview explains how request construction and response analysis shape this work.
The same principle extends to GraphQL, where the scanner can build queries from a schema and then vary specific fields or arguments rather than testing only the queries a client would normally send.
The result has meaning only when the scanner knows what should have happened. A successful request may reveal a flaw, but it may also represent permitted behavior. Expected roles and application state help separate the two.
Staying Authenticated During Testing
Protected routes often require a session cookie, API key, or OAuth token. A scanner that loses access can still finish its run, but everything after that point is testing a login page rather than the application, and a clean-looking report won’t show the difference.
DAST tools can record a sign-in flow, place tokens in headers, and refresh credentials when they expire. Some workflows also require the scanner to capture a value from one response and reuse it in the next. These steps keep the test inside the application.
Microservices can change the identity attached to a request. A customer token may reach the gateway, while downstream calls use a service identity. External and internal scans can therefore produce different views of the same transaction.
Comparing Permissions Across Accounts
One authenticated session can confirm access. It cannot show whether the access boundary is correct.
The scanner can repeat the same request as the object owner, another customer, or an administrator. It can then change an identifier or field and compare what each identity can read or modify. Guidance on broken object-level authorization describes how attackers manipulate identifiers carried in requests.
This is especially useful in multi-tenant systems. Test accounts from different organizations can reveal cross-tenant exposure that would look ordinary in a single-user scan. The scanner handles the repetition. The security team defines the identities and permissions.
Testing Beyond the API Gateway
A public scan often sees the application through an API gateway. That view may hide how a service behaves when called directly.
Gateways commonly handle routing, authentication, and request validation. A service mesh may add controls between workloads. The CNCF Cloud Native Security whitepaper explains how service meshes support communication and security between services.
An internal scan can reach direct service endpoints or older versions that are not exposed through the public gateway. Comparing the two views may uncover uneven enforcement. A malformed payload rejected at the gateway, for example, may still be accepted by the underlying service.
This gap can appear after a routing or deployment change. The code may be unchanged, yet a previously unreachable endpoint can become accessible through a new network path.
Following Multistep Service Workflows
Some weaknesses appear only across several valid calls. A refund may require an order lookup, eligibility check, approval, and payment instruction. Each endpoint can behave correctly on its own while the full sequence allows approval to be skipped or a token to be reused.
DAST tools can record a legitimate workflow and preserve values from earlier responses. The scanner can then repeat a step, change the order, replace an identifier, or submit a request after the application should have moved to another state.
These tests need controlled accounts and data. A workflow that issues a refund or calls a third-party service can produce a real effect. The test environment should let the scanner explore the sequence without disrupting operations.
Showing What Was Actually Tested
A clean report has limited value when the scan reaches only public routes or stays authenticated for a few minutes. Coverage needs evidence of its own.
Teams should be able to see which definitions were imported, which endpoints were exercised, and whether sessions remained active.
They should also know which identities were used and whether internal services were included. Findings need enough request and response detail for a developer to reproduce the behavior.
A Scan Is Only as Complete as Its Context
DAST tools test APIs and microservices through discovery, valid application state, controlled request changes, identity comparison, and workflow execution. The scanner automates those actions, but the organization determines what it can see and which results it can interpret correctly.
As applications become more distributed, gaps in context can shape the outcome as much as the scanner itself. An incomplete inventory or expired session may leave critical routes untested. A missing role or unseen internal path can create the same false reassurance. Effective dynamic testing therefore needs evidence of coverage alongside evidence of vulnerabilities.
