DAST scan-readiness and coverage checklist

Download Markdown

Use this worksheet to prepare a scan and record what the run actually established. A checked item records evidence or a decision; it does not certify that an application is secure.

Record the run

• Application and build/commit:
• Environment and target origin:
• Run identifier and date:
• Person responsible for the run:
• Tool/version and scan policy:
• Location of the report and sanitized evidence:

Before the run

• Confirm the application and operations are within the agreed testing scope.
• Select the environment and representative test data for the intended checks.
• Identify operations that need exclusion or special handling, such as payments, destructive actions, outbound messages, or account changes.
• Set appropriate scheduling, request-rate controls, and stop conditions for the environment.
• List the important pages, API operations, and workflows the run is intended to assess.
• Identify the test identities and roles needed to reach those areas.
• Configure authentication and session handling where required.
• Supply supported API definitions or other discovery inputs where relevant.
• Record whether the run will perform passive analysis, active tests, or both, and which rules/policies apply.

Check reach and coverage

• Verify that the configured identity can reach expected authenticated content.
• Check for expired sessions, login redirects, or responses that only repeat a login page.
• Compare important intended routes/operations with the available discovery and request evidence.
• Record inputs or workflows that were not reached, failed, or were excluded.
• Distinguish an observed page/response from evidence that its inputs, states, and authorization boundaries were tested.
• Record relevant changes in role, configuration, policy, or target during the run.

For each important application area, record its intended identity, observed evidence, checks actually applied, and unresolved limitations. Use "not assessed" when there is no supporting evidence.

Review the result

• Confirm that the scan completed as intended rather than stopping early or running a different mode.
• Review findings with their affected location, request/response evidence, confidence, and application context.
• Keep sensitive data and credentials out of exported evidence.
• Record who will investigate each actionable finding and where its status is tracked.
• Describe the limits of a clean result using the recorded scope, identities, inputs, and policies.
• Plan application-specific authorization and business-workflow tests where general-purpose scanning does not establish the required behavior.

Check a fix

• Identify the original finding and the build containing the proposed fix.
• Repeat the relevant test with comparable scope, identity, inputs, and policy.
• Preserve the new evidence and explain any differences from the original run.
• Check that an absent alert was not caused by failed authentication, reduced reach, changed rules, or a skipped test.
• Add a repeatable regression check where suitable and retain ownership of any remaining uncertainty.

Documentation behind the checklist

• ZAP authentication and authentication statistics
• ZAP URL/request/response presence tests
• ZAP Baseline Scan
• ZAP API Scan
• ZAP active-scanning scope and limitations
• OWASP testing for insecure direct object references
• OWASP introduction to business-logic testing

Documentation checked November 12, 2026. This is an original editorial worksheet informed by those sources, not a scanner benchmark or a reproduction of their procedures.