Examples in this article are illustrative, not customer case studies. Product availability and coverage are described on the linked capability pages.
A DAST scan can finish without findings because it never got past the login page. Before trusting a quiet report, prove which authenticated routes the scanner reached and whether its session stayed valid throughout the test.
Use a fictional order-management application as the worked example. Customers can read their orders, support staff can inspect delivery status, and an administrator manages configuration. The exercise takes place in an authorised test environment with synthetic accounts and records. Its purpose is to build a reliable scan contract, not to treat automated testing as a complete security assessment.
Authenticated DAST needs an explicit access contract
List the approved hosts, environments and test accounts before selecting scan rules. Record permitted actions as well as exclusions. An order cancellation endpoint may be in the inventory but excluded from active testing until the team has disposable data and a recovery procedure.
Give each test identity the permissions needed for its scenario. Do not use one broad administrator account as a shortcut for every role: it changes what the scanner can observe and leaves ordinary customer behaviour untested. Keep account ownership and reset procedures in the test plan so a departed engineer does not leave behind an unmanaged testing identity.
The contract should also describe what constitutes an incomplete run. Authentication failure, an unavailable test service and an interrupted crawl are different from a completed scan with no findings. Those distinctions must survive into the report and pipeline result.
Prove login by observing a protected resource
A successful response from a login request does not by itself establish that the scanner has a usable session. Applications may return a challenge, an intermediate page or a generic success response while protected routes still redirect to authentication. Choose an application-specific protected resource that reliably demonstrates the expected session state.
For the order-management example, use a synthetic customer’s order list. Confirm both the expected authenticated identity and the expected type of response. If every request returns an HTML login screen with a successful status code, counting those responses as explored API routes would overstate coverage.
ZAP models authentication, session management and logged-in or logged-out indicators within a context. Those settings address different parts of the problem: obtaining a session, maintaining its state and detecting whether it is still usable. Configure and test each part rather than assuming the presence of credentials completes the setup.
Authenticated DAST must survive session changes
Sessions expire, tokens rotate and anti-forgery values change. A scan that reaches a protected page at the beginning can become unauthenticated later. In the test environment, deliberately expire the session and observe whether the automation reauthenticates correctly or marks the affected part of the run incomplete.
Avoid placing reusable credentials directly in a checked-in scan plan or report. Use the secret-delivery mechanism approved for the runner, and restrict access to logs that could contain session material. The evidence you retain should show that authentication worked without distributing a working token to everyone who can read the result.
Keep an audit note when the login flow changes. A new identity provider, consent page or challenge can invalidate a previously reliable automation plan. Recheck the protected resource after those changes instead of relying on the fact that last week’s pipeline was green.
Measure route coverage independently of alert totals
Build a small route matrix from the application’s approved inventory. Include method, route template, role, expected response type and whether the route was reached during this run. Use templates such as an order identifier placeholder rather than retaining customer-specific URLs in a broadly accessible report.
| Route group | Customer test | Support test | Evidence to retain |
|---|---|---|---|
| Order list | Expected to be reachable | Depends on assigned scope | Session identity and response class |
| Order detail | Own synthetic orders only | Approved support scope | Route template and test fixture |
| Configuration | Expected to be denied | Expected to be denied | Denial behaviour, separately tested |
| Cancellation | Excluded until explicitly enabled | Excluded until explicitly enabled | Exclusion reason and owner |
Compare discovered routes with that matrix before evaluating findings. Missing routes may reflect a broken crawl, inaccessible navigation, missing API definitions or an intentional exclusion. Each cause needs a different response. “The scanner did not report a problem” is not an answer to whether the route was tested.
Coverage is also a time-bound observation. Record the application revision, scan configuration and environment so a later result can be compared with a meaningful baseline. A route added after the scan was never part of its tested surface.
Separate authentication coverage from authorisation testing
Reaching a resource while logged in does not establish that access control is correct. Authorisation testing needs explicit expectations about which identity may perform which action on which object. For the fictional application, a customer reading their own order and being denied another customer’s order are two different checks.
Use purpose-built, controlled fixtures for those checks and keep them inside the agreed environment. Do not assume that a general-purpose crawl will generate every relevant combination of identity, object and action. A complete review may combine automated requests with manual assessment and application-level tests.
The API inventory guide explains how to establish the route and ownership record that makes this work manageable. Without that inventory, teams can repeatedly test the easiest paths while overlooking older versions and administrative endpoints.
Make the result useful to the next engineer
Retain a concise run record: application revision, environment, account role, authentication verification, reached route groups, exclusions and failure reasons. Link findings to the relevant evidence, with sensitive request content handled according to your retention policy. A recipient should not need access to live credentials to understand why the scan was considered complete or incomplete.
When a scan regresses, reproduce the access problem before changing alert thresholds. Otherwise a team can make the pipeline quieter while making coverage worse. Fix the authentication or discovery issue, rerun the agreed scope, and compare coverage before deciding what the alert changes mean.
Key takeaways
- Verify an authenticated session against a protected resource rather than relying on login status alone.
- Test session expiry and distinguish incomplete scans from completed scans with no findings.
- Track route and role coverage separately from alert counts.
- Treat authorisation checks as explicit identity, object and action tests within an approved scope.
How SecurityVault approaches this
SecurityVault brings dynamic application findings into the same investigation context as source, artefact and workload evidence. The DAST capability page describes the running-application side of that workflow. Connected context helps an engineer understand which application and environment a finding concerns, but it does not prove that an authenticated scan reached every relevant route.
An evaluation should therefore include the scan setup and coverage evidence, not only the imported findings. Agree the test environment, account roles, exclusions and success conditions before running a demonstration. Ask how an authentication failure is represented and whether an incomplete result remains distinguishable from a completed assessment.
Dynamic findings can then be investigated alongside other analysis and routed to an accountable team. Human review is still required to interpret the evidence and decide the next action. To walk through an authorised example using the authentication flow and deployment model your team actually operates, request a technical demonstration.