What authenticated DAST actually costs
On this page
There are two very different activities that both get called DAST, and conflating them produces most of the confusion about whether dynamic scanning is worth doing.
Unauthenticated scanning points a tool at a URL and checks what any stranger could reach. Authenticated scanning logs in, holds a session, and exercises the application as a user.
The second is where the findings are. It is also substantially harder to run, and that gap, not any deficiency in the idea, is why so many pipelines end up running the first and concluding DAST does not find much.
What the unauthenticated scan is for
It is not useless. It answers a specific, worthwhile question: what is exposed to someone with no credentials at all?
- A debug endpoint or admin panel reachable from the internet.
/.git/served as static files, a directory listing, a stack trace on error.- Default credentials on an embedded component.
- A version banner matching a known CVE.
- Anything that appeared since the last check, which a point-in-time review structurally cannot catch.
That list is short, cheap to check, and full of things that start real incidents. It is a perimeter check, and perimeter checks are worth running continuously precisely because they are cheap.
What it is not is a measure of your application's security. Quoting a clean unauthenticated result as though it covered the application is where the misleading happens, and it is usually unintentional, because the report does not say which surface it saw.
What authenticated scanning costs
Everything that makes it valuable also makes it awkward to automate:
| What it needs | What it looks like when it is missing |
|---|---|
| Credentials that exist and are managed | a test account in a secret store, rotated, and scoped so the scan cannot do anything irreversible |
| A session that survives the scan | login flows, tokens expiring mid-run, CSRF tokens, MFA. Most attempts fail here |
| Destructive actions excluded | a scanner exercising authenticated endpoints finds the delete button. Ask anyone who has run one against shared staging |
| A specification, for an API | there is no HTML to crawl, so an API scan without an OpenAPI document sees almost nothing |
None of this is exotic. ZAP and Burp have supported all of it for years, and teams run it successfully every day. It is setup, and setup is what does not survive being bolted onto a pipeline as an afterthought.
Point it somewhere you can afford to break
A dynamic scan is not an observer. It submits forms, follows every link it finds, and sends inputs chosen to provoke a reaction, and once it holds a session it does all of that as somebody with permissions.
What it does to the data
It finds the delete button and presses it. It sends the invitation emails, fires the webhooks, and posts the records, because from inside a session those are just endpoints that accept a request. Anything irreversible is reachable by a tool with no idea which actions you meant.
What it does to everything else
It is traffic, enough to slow a service or take one down. It will trip your own rate limits, light up the WAF, and page whoever is on call, and on shared infrastructure that can look like an attack to a provider who was not told.
So the authenticated scan belongs against an environment you control, holding data you can throw away, with a test account scoped so the worst it can do is undone by a reset. That environment is the real cost of this kind of scanning, and it is the reason the setup so often stalls.
Where there is genuinely no such environment, and for plenty of teams there is not, the honest position is to keep the perimeter scan, which is unauthenticated and reads rather than writes, and to schedule the authenticated one for when a staging environment exists. Running it against production because staging does not exist trades an unmeasured security risk for a certain operational one.
What Draugr's dast covers
The perimeter by default, on every release. Draugr's dast control runs Nuclei against the URL a
component declares, checked continuously, as part of the same descriptor and the same verdict as
everything else it looks at.
That is the half worth automating into a gate, and it is the half most teams do not run at all, because standing up a scan per service is a job nobody has time for. Declaring a host in a Saga is one line, and the check comes with the pipeline you already have.
Two of the costs above are declarations rather than infrastructure. A host carries an auth:
block naming the environment variable that holds a token, and there is no field for the credential
itself, because a descriptor is committed:
hosts:
- url: https://api.example.com
auth:
type: bearer
tokenEnv: DRAUGR_API_TOKENThe pipeline sets DRAUGR_TOKEN_ENVS=DRAUGR_API_TOKEN to allow that variable, and a descriptor
naming one the pipeline has not listed fails the scan. So does an unset variable, rather than
quietly falling back to anonymous, which would produce exactly the misleading pass this is meant to
prevent. Point the same host at an openapi.yaml and
it exercises the routes the API declares instead of crawling for them.
What that does not buy you is the session handling described earlier. A bearer token is not a login flow, and an API with a short-lived session still needs the machinery this post is about. The descriptor covers the cases where a credential is a header, which is most APIs and few browser applications.
A spec-driven scan is read-only unless you say otherwise. A specification lists DELETE too,
and a scanner handed one will use it, so operations whose method you have not named are removed
before the scanner sees the document, and the scan targets the endpoint your descriptor declared
rather than the one the specification names.
Draugr never turns dast on for you. Even when discovery finds a host, it stays off, because
this control sends probing traffic at a live service and enabling that on the strength of a
descriptor mentioning a URL is not a decision a tool should make on somebody's behalf.
The comparison worth drawing instead
The useful axis is not scanner versus pentester but breadth against depth, on a schedule.
A perimeter scan is cheap enough to run on every release, so it catches the thing that changed. An authenticated scan costs setup and is worth running on a slower cadence against an environment you control. A pentest understands what your application is for. That user 41 should not read user 42's invoices, and no scanner ever will, because the logic being violated exists only in your requirements.
Three tools, three cadences, three questions. The mistake is expecting any one of them to answer another's.
The DAST guide covers what dynamic scanners check and how they differ, and HTTP security headers covers the passive half of the same surface.