Skip to main content

Dynamic Security Testing (DAST)

🌟 Objective​

To detect vulnerabilities in applications while they are running, simulating the behaviour of a user or an attacker, with the aim of:

  • Identifying flaws that are not visible in the code (e.g. injections, authentication bypass);
  • Validating the real configuration of the environment (e.g. headers, permissions, exposure of services);
  • Testing complete flows and interactions with the running application;
  • Complementing static testing (SAST) with runtime visibility.

DAST is essential for testing what is only revealed when the application is actually running.

🔍 What DAST is​

DAST (Dynamic Application Security Testing) consists of running automated security tests against a running application (usually in staging or in controlled environments), simulating malicious or erroneous external behaviour.

It may include:

  • Injection attacks (SQLi, XSS, command injection);
  • Manipulation of sessions, cookies and authentication;
  • Exploitation of public endpoints or APIs;
  • Verification of security headers (e.g. CSP, HSTS, CORS);
  • Tests of multi-step workflows.

⚠️ DAST requires a runnable environment and configured authentication to simulate real users.

⚙️ How to apply​

  1. Prepare an isolated staging or pre-production environment, with controlled data;
  2. Select a DAST scanner suited to the application type (web, API, mobile);
  3. Configure authentication, scope and appropriate crawling;
  4. Run regular scans per version or per release;
  5. Review findings manually before triggering remediation actions;
  6. Integrate results in the backlog, with traceability by artefact or release.

💡 Suggestion: define distinct scan profiles per application type (e.g. portal vs REST API).

✅ Good practices​

  • Automate DAST execution in the pipeline, but outside the critical path (e.g. a validation environment);
  • Use fictitious or masked data;
  • Avoid destructive tests in shared environments;
  • Configure timeouts, multi-user authentication and session fallback;
  • Review scan scopes after changes to the architecture or routes;
  • Include APIs and external integration points.

📎 Cross-references​

DocumentStrategic relevance
Chapter 02 - RequirementsValidates EX-REQ-208, EX-REQ-310, EX-REQ-405
Chapter 07 - Secure CI/CDIntegration with parallel pipelines
04-fuzzing.mdComplements dynamic validation with randomness
06-cobertura-e-priorizacao.mdDefines the criticality of the endpoints to be tested
08-gestao-findings.mdManagement of results and follow-up
09-feedback-equipa.mdInvolvement of the QA and DevOps teams

Illustrative identifiers (EX-…); they do not correspond to the Ch. 02 Requirements Catalogue.

🔍 DAST sees what the code hides: integration flaws, unexpected responses and risks arising from the real execution environment. It is the external lens on application security.