How to perform security testing (DAST)

How to perform security testing (DAST)

Security testing checks that confidential data stays confidential, that users can only do what they are allowed to do, and that the application cannot be turned against its owners or users. For a web application or API, the most repeatable way to do this is dynamic application security testing (DAST): attacking the running application the way an outsider would, and recording the evidence.

This guide walks through a DAST engagement end to end, using Vooki Pro as the example.

1. Get permission and set scope

  • Only test systems you own or have written permission to test. Active testing sends real attack payloads.
  • Agree which hosts are in scope. Third-party services such as payment providers, analytics and CDNs are usually out of scope.
  • Test staging first. Scans can create records, send emails, trip rate limits and trigger WAF rules.
  • Get a dedicated test account for each role you need to test (user, admin). Never use a real customer's account.

2. Map the attack surface

You can only test what you have found. Combine these approaches:

  • Crawling for traditional multi-page sites.
  • Browser recording for single-page apps, multi-step flows and SSO logins.
  • Background request capture for the XHR and fetch calls behind a modern front end.
  • API specs (OpenAPI, Postman, HAR) for REST services.

In Vooki Pro, this is the Discovery step. Use Hybrid for single-page apps. For APIs, import the spec into the API Builder.

3. Authenticate

An unauthenticated test only covers the login page. Configure credentials (a token, cookie, form login, OAuth2 client credentials or a recorded login) and turn on auto re-login so a session timeout does not silently end the authenticated part of the test.

4. Choose what to test and how hard

Match the depth to the goal:

  • First look at an unfamiliar host: a Quick policy.
  • Regular testing: Standard (OWASP Top 10 essentials).
  • Before a release or audit: Deep or Default, run overnight.
  • Production: a custom policy without destructive and denial-of-service checks, at Stealth speed.

5. Run the test and check coverage

Before you read the findings, check how much the test actually reached. A scan that found little because the app is clean looks the same as one that found little because discovery or login failed. The coverage numbers and logs tell you which it was.

6. Triage the findings

  • Read the request and response evidence for each finding, not just its title.
  • Mark false positives so they stay out of later reports.
  • Prioritise by severity and exposure. A High on a public login page comes before a Medium on an internal admin page.
  • File tickets with the evidence and remediation attached.

7. Fix, retest, report

  • When a fix ships, retest that specific finding instead of rerunning everything.
  • Give developers a standard technical report and auditors a compliance report (OWASP, PCI DSS, NIST, ISO 27001, HIPAA, GDPR, SOC 2).
  • Schedule the scan so testing keeps pace with releases, and add it to CI/CD with a severity gate.

Automated scanning and manual testing

Automated scanning finds the broad, repeatable classes of bugs quickly and consistently. It does not replace a skilled human looking for business-logic flaws and chained attacks. Most mature programmes use both: DAST continuously, and a manual penetration test periodically.

Try it: How to run a web application scan ยท Vulnerability assessment checklist