What Is Dynamic Application Security Testing (DAST)?

Dynamic testing attacks a running application from the outside, with no access to source. It sees what an attacker sees — the deployed system, its configuration, its actual behaviour — which is exactly what static analysis cannot.

The trade is coverage. It finds only what it can reach, and reaching things in a modern application is harder than it sounds.

What it uniquely catches

It is also language-agnostic, which matters in estates where several stacks are in use and maintaining static analysis for each is a real cost.

The coverage problem

A scanner has to find functionality before it can test it, and modern applications hide their functionality behind authentication, multi-step workflows and client-side rendering.

Unauthenticated scanning of an authenticated application is the most common waste of a DAST licence. It produces a clean report about the two pages an anonymous user can see. Configure credentials, verify the scanner is actually holding a session, and check the crawl coverage before believing any result.

Where it fits in the pipeline

DAST is too slow and too noisy to gate a build on. It belongs on a schedule against a staging environment that resembles production, or against production with care and agreement.

It also carries risk that static analysis does not: a scanner submitting forms can create records, trigger workflows, send emails and, against the wrong environment, delete data. Run it against an environment where that is acceptable, and never point it at production casually.

Modern applications make crawling hard

Dynamic scanners were designed for applications that returned complete pages of links. Contemporary front ends render client side, load content on interaction, and expose functionality only after a sequence of steps — all of which defeats a conventional crawler.

The consequences are worth naming because they are easy to miss. A scanner that cannot execute the front end will see a nearly empty application. One that cannot complete a multi-step workflow will never reach the functionality behind it. One that cannot maintain a session will silently test the login page repeatedly and report cleanly.

Two things help materially. Point the scanner at the API directly using a specification, so it tests endpoints without needing to discover them through the interface. And seed it with recorded traffic from your functional test suite, which teaches it the workflows a crawler cannot infer. Both convert a superficial scan into a useful one.

Where to start

Look at the crawl coverage of your last scan. If the scanner authenticated and reached a meaningful share of the application, the findings mean something. If it did not, fix that before reading the findings.

See scanning versus penetration testing, since dynamic scanning is frequently mistaken for a penetration test. GuardsArm delivers application penetration testing.