DAST for APIs: Why Your Scanner Stops at the Login Page

Your dynamic scanner ran last night and the report is clean. Before you take that as good news, ask two questions: did it log in, and did it know your APIs existed?

In many organizations the honest answer is no. The scanner crawled the public pages, hit the login form, found nothing to click and stopped. Meanwhile most of the business logic, and most of the data, sits behind authenticated API endpoints that have no links pointing to them. A clean report from that setup says very little about the part of the application attackers care about most.

This guide explains what DAST does well, why APIs break the classic setup, and how to configure dynamic testing so a clean result actually means something.

What DAST is, and what it is not

Dynamic Application Security Testing (DAST) tests a running application from the outside. The OWASP DevSecOps Guideline describes it as black-box testing that finds vulnerabilities and weaknesses in a live application without needing its source code. It is especially useful for input and output validation problems, authentication issues and server configuration mistakes.

That makes it a complement to static techniques, not a replacement. SAST reads your code, SCA checks your dependencies, secrets and IaC scanners check what you commit; DAST checks how the deployed system actually behaves. We compared the static side in SAST, SCA, secrets and IaC explained.

NIST's Secure Software Development Framework (SP 800-218) points in the same direction. Practice PW.8, "Test executable code to identify vulnerabilities," lists among its implementation examples:

• Integrate dynamic vulnerability testing into the project's automated test suite.
• Use fuzz testing tools to find issues with input handling.
• If resources are available, use penetration testing to simulate how an attacker might attempt to compromise the software in high-risk scenarios.

It also asks teams to record and triage every finding in the development team's workflow or issue tracker. A report nobody reads does not count as testing.

Why APIs break the classic DAST setup

1. There are no links to follow

A traditional web scanner discovers pages by crawling: it follows links and submits forms. An API has no links. Endpoints like a customer lookup or an order update only exist in client code and documentation.

That is why API scanning starts from a definition. The ZAP project's guidance on scanning APIs is built around importing an OpenAPI or SOAP definition so the scanner knows which endpoints and parameters to test. It also recommends supplying realistic test values, because default inputs may not exercise enough of the code path.

2. Everything interesting is behind authentication

If the scanner never authenticates, it only tests what an anonymous visitor can reach. ZAP's documentation explains that authentication lets a scan reach content that is only available after login, and that you must tell the tool how to recognize whether it is still logged in, with a logged-in or logged-out indicator. Without that check, a scan can silently lose its session halfway through and keep reporting results from the login page.

For token-based APIs, ZAP's API guidance suggests obtaining the token through your normal process and adding it as a header to every request the scanner sends.

3. The worst API flaws are authorization flaws

Look at the OWASP API Security Top 10 (2023 edition). Three of the ten risks are about authorization:

• API1:2023 Broken Object Level Authorization (BOLA): a user changes an object ID in a request and gets someone else's record.
• API3:2023 Broken Object Property Level Authorization: a user can read or change fields of an object they should not.
• API5:2023 Broken Function Level Authorization: a regular user can call an admin function.

OWASP rates BOLA as widespread and easy to exploit, and says failures typically lead to unauthorized disclosure, modification or destruction of data. Its first recommendation is a proper authorization check on every function that uses client input to access a record, and it explicitly recommends writing tests that evaluate the authorization mechanism.

Here is the catch: a scan that runs as a single user cannot tell whether user A can read user B's data, because it only ever sees one side. The OWASP testing guidance for insecure direct object references says the best way to test is with at least two users, often more, owning different objects and holding different roles, and then swapping their identifiers.

4. You cannot test the API you do not know about

API9:2023, Improper Inventory Management, covers old versions, forgotten hosts and undocumented endpoints. OWASP recommends inventorying every API host with its environment, its audience (public, internal or partners) and its version, generating documentation automatically from open standards in the CI/CD pipeline, and protecting every exposed version, not only the current one.

For DAST this matters directly. If your scan reads the spec of v2 while v1 is still online, the scanner never touches the endpoint most likely to be missing the latest fixes.

A practical setup that makes "clean" mean something

1. Generate the API definition in the pipeline. Build the OpenAPI document from the code in CI, as OWASP API9 recommends, and feed that same file to the scanner. A hand-maintained spec drifts.
2. Scan authenticated, in a test environment. Use dedicated test accounts and configure a logged-in indicator so you know the session held. Active scans send attack-like requests, so point them at staging, not production data.
3. Use at least two users with different roles. One regular user, one with other data, one admin. That is the minimum to test BOLA and function-level authorization.
4. Tune the rules for APIs. ZAP's API scan profile disables rules aimed at browser issues such as cross-site scripting and adds checks for unexpected status codes and content types. Fewer irrelevant alerts means developers read the rest.
5. Run it on a schedule and on release. The OWASP DevSecOps Guideline notes DAST can run as a nightly scan. Add a run before major releases.
6. Inventory every version and host. Scan what is actually exposed, including old versions and partner endpoints, not just what is in the latest spec.
7. Keep humans for the sensitive parts. ZAP's own guidance warns that a clean scan does not guarantee safety and suggests a manual penetration test for sensitive APIs. NIST PW.8.2 says the same for high-risk scenarios.
8. Send findings where work happens. Record and triage results in the development team's tracker, per NIST PW.8.2, and rank them alongside the rest of your vulnerability backlog. An authorization bug on an internet-facing payments API is not the same as a missing header on an internal test tool; see why internet exposure changes priority.

Frequently asked questions

Does DAST replace SAST or a penetration test? No. DAST sees runtime behavior that static tools miss, static tools see code paths a scanner never reaches, and a skilled tester finds business-logic flaws that neither automates well.

Can I run DAST against production? Passive checks are low risk, but active scans send malicious-looking input that can create or change data. Run active scans against a staging environment that mirrors production, and if production data must be used there, protect it like production, as OWASP API9 advises.

Our scanner supports GraphQL. Is the advice different? The principles are the same: give the tool the schema, authenticate it, and test authorization with more than one user.

How do we decide which DAST findings to fix first? The same way as any other finding: exploitability, exposure and business impact, not the scanner's label alone. Our guide on how to prioritize vulnerabilities walks through it.

How priorIQ.ai helps

CodeIQ covers the static side of application security: SAST, SCA, IaC and secrets scanning, with AI triage and verified fixes opened as pull requests. Findings from your dynamic testing tools sit alongside them: PriorIQ Core connects to your scanners, deduplicates their results with the findings from CodeIQ and your other modules, and ranks everything by real risk, so the authorization bug on an exposed API does not get lost under a thousand low-value alerts. Request a demo.