Why traditional DAST misses your API vulnerabilities (and how to fix it in CI/CD)

Short answer: traditional DAST scanners miss most API vulnerabilities because they crawl HTML pages an API does not have, ignore the schema that defines its real attack surface, and test for injection instead of the broken-authorization flaws that cause actual API breaches. The fix is schema-aware, authenticated testing wired into CI/CD so it runs on every pull request. The rest of this article shows why the old model breaks and how to close the gap.

In September 2022 an attacker walked off with the personal records of up to 10 million Optus customers, close to 40% of Australia, straight out of a public API (as Reuters reported). No exploit chain, no zero-day. The endpoint required no authentication and returned a customer record for whatever identifier you asked for, so the attacker just counted upward and collected the lot. A conventional DAST scanner pointed at that service would almost certainly have reported nothing wrong.

That gap is what this article is about. Most dynamic application security testing tools were built for a web of server-rendered pages and HTML forms, and they quietly fall apart on the APIs that now carry the bulk of application traffic. The analyst firm Gartner had already projected that API abuses would become the leading attack vector behind enterprise data breaches (via VentureBeat), and incidents like Optus turned that forecast into routine news. What follows is why classic scanners miss API flaws, a bug one will never flag, and how to get real API coverage running on every pull request.

What traditional DAST was built to do

Start with a clean definition, because the gap follows straight from it. Dynamic application security testing is a black-box method: it probes a running application from the outside, with no access to the source code, and watches how the system answers a stream of simulated attacks. That outside-in stance is what separates it from its two siblings, and the three approaches split the work like this:

A first-generation DAST tool earns its findings by crawling. It loads a URL, parses every link and form, follows them to map the application, then fuzzes each input it found with injection strings and watches for something to break. The model rested on one assumption that held for years: the application advertises its own attack surface through HTML. A server-rendered monolith did exactly that, which is also why DAST automates the kind of probing a penetration tester does by hand, scaling to every build without ever fully replacing a human's creativity.

Why that model breaks on modern APIs

An API-first architecture violates that assumption point by point. There are no pages to crawl, the inputs live in a schema the scanner cannot see, and the credentials are harder to carry than a cookie. Point a crawler at a JSON API and it loads one shell document, finds almost nothing to follow, and returns a short clean report that reflects its own blindness rather than your security.

That last row is the one that matters most. The vulnerabilities behind real API breaches are rarely malformed-input bugs; they are failures of authorization and business logic, and they arrive as perfectly valid requests the application should have refused. The OWASP API Security Top 10 makes the point bluntly, with access-control failures leading the list rather than injection:

• Broken object level authorization (BOLA): a user reaches another user's data by changing an identifier. This was the Optus root cause, and OWASP ranks it the number-one API risk.
• Broken authentication: tokens that can be forged, replayed, or that never expire.
• Broken object property level authorization: mass assignment and over-exposed fields.
• Broken function level authorization: a standard user invoking an admin-only operation.

None of these surface by throwing injection strings at a parameter. Catching them means reasoning about who is allowed to do what, which a crawl-and-fuzz tool was never built to do.

A concrete example: the BOLA your scanner will never find

Here is the Optus pattern in miniature. A legitimate request from user A returns their own order:

GET /api/v1/orders/1023 HTTP/1.1
Host: api.example.com
Authorization: Bearer <user_A_token>

200 OK
{ "id": 1023, "customer": "user_A", "total": 84.20 }

Now user A changes one digit and asks for a different order, still with their own valid token:

GET /api/v1/orders/1024 HTTP/1.1
Host: api.example.com
Authorization: Bearer <user_A_token>

200 OK
{ "id": 1024, "customer": "user_B", "total": 311.00 }

The second response is the breach. User A read user B's order because the backend confirmed the token was valid but never checked that the order belonged to the caller. To a scanner, nothing looks wrong: the request is well formed, there is no injection signature, and the server returns a clean 200. That is exactly how millions of records left Optus, one incremented identifier at a time.

GraphQL hides the same class of bug behind a single endpoint. A scanner sees one URL at /graphql and treats it as one page, while in practice that endpoint exposes dozens of queries and mutations, each with its own authorization rules. A query fetching user(id: 1024) { email } with the wrong caller's token is the same BOLA in different syntax, and the crawler is even less equipped to spot it, since it cannot enumerate the operations without the schema.

How to fix it in CI/CD

Closing the gap is not a matter of a better fuzzer. It needs testing that understands your schema, carries real credentials, and reasons about authorization, wired into the pipeline so it runs on every change instead of once a quarter. Four moves get you there:

1. Feed the tester your schema. Hand it your OpenAPI spec, or enable GraphQL introspection in staging, so it enumerates every endpoint instead of guessing at them. This alone turns an invisible surface into a testable one.

2. Make authentication a first-class input. Give it a real token flow and let it refresh mid-scan. With OAuth, SAML, SSO or MFA steps in play, the tool has to follow the flow rather than stall on a wall of 401s.

3. Test across more than one identity. Send a request as user A, replay it as user B, and check whether B can reach A's data. Single-user scanning can never catch BOLA, because the bug only exists in the relationship between two users.

4. Gate the build. Run the scan on each pull request against a staging deploy and fail on serious findings, so the outcome is a gate rather than a report nobody opens.

Most API-aware scanners ship a CI integration that bundles these moves. As a concrete, runnable example, Escape's official GitHub Action runs a scan on every pull request and fails the job when it finds something serious:

# https://github.com/Escape-Technologies/action
name: api-security
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  escape-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Escape DAST scan
        uses: Escape-Technologies/action@v0
        with:
          application_id: ${{ secrets.ESCAPE_APPLICATION_ID }}
          api_key: ${{ secrets.ESCAPE_API_KEY }}

The application carries its own schema, authentication and test configuration on the platform, so the workflow itself stays this short. Swap in another vendor's action and the shape is the same; what matters is that the scan is wired to the pull request rather than left as a quarterly chore.

That fourth move is what shifting DAST left actually means: a fast, scoped check on every change rather than one heavy scan late in the cycle. Incremental scanning keeps it quick enough on large APIs to stay out of the team's way, and it heads off the alert fatigue that quietly kills most DAST programs. Run it continuously and a flaw turns up in code review, where it costs minutes, instead of in a breach notification.

Where Escape fits

If you want a tool built for the category above rather than a legacy scanner retrofitted onto APIs, Escape was designed around it from the start. It can work from your OpenAPI specification or GraphQL schema rather than depending on link-crawling alone, goes deep on REST and GraphQL with additional protocols like gRPC and SOAP available, and authenticates against the token and session flows that break older tools. That is what lets it reach the endpoints a traditional scanner never sees.

For the bugs in this article, its core focus is business logic and authorization testing rather than only fuzzing for injection, so the BOLA example earlier is exactly the kind of finding it is built to surface. If you are wondering whether that is just a crawler with better marketing, the engineering team has written up how the business-logic engine actually works. It runs in CI/CD pipelines with pass/fail gates, and it validates findings before reporting them, which is how tools in this space keep the false positive rate low enough that developers actually trust the output.

It is not the only option here, and the right choice depends on your stack and team. To weigh the trade-offs, this comparison of how the main DAST tools handle REST and GraphQL lays out where each one is strong and where it falls short, including API protocol support, CI/CD depth, and authentication handling.

How to layer it without ripping anything out

You do not need to tear out your existing scanner. If you run something like OWASP ZAP, keep it for the classic injection and configuration checks it does well, and add API-aware testing alongside it rather than treating one tool as the whole picture. DAST is also no substitute for the rest of your program: it will not catch a hardcoded secret the way SAST does, or a vulnerable dependency the way software composition analysis does, and it complements rather than replaces periodic manual penetration testing.

A workable order is to export an accurate schema first, since everything depends on the tool knowing your real surface, then wire up authentication, then add cross-user testing, and finally promote the job to a required check once the signal is clean. If you are not even sure how many APIs you have, begin with API discovery to surface the shadow APIs that breaches like Optus thrive on. Each step narrows the blind spot on its own, so there is no need to finish all of it before it starts paying off.

The takeaway

Traditional DAST is not broken; it is scoped to a problem that no longer matches how software is built. When the product is an API, the attack surface is invisible to a crawler, the credentials are harder to carry, and the vulnerabilities that count are about authorization rather than injection. A scanner built for the old shape keeps returning green while an attacker counts upward through your identifiers.

The fix is concrete: give the tool your schema, let it authenticate like a real client, test across identities, and run it on every pull request. Do that, and the BOLA that would otherwise become a headline shows up in a code review instead.