What Is DAST? Dynamic Application Security Testing Explained for Dev Teams

DAST in 30 seconds

Dynamic Application Security Testing sends actual HTTP requests to your running application and analyzes the responses for signs of vulnerabilities. It’s essentially automated penetration testing — the tool acts like an attacker, poking at your app from the outside, looking for cracks.

Unlike SAST, which reads your source code, DAST doesn’t care what language your app is written in or how your code is structured. It only sees what an external attacker sees: URLs, forms, APIs, cookies, and HTTP responses.

That’s both its superpower and its limitation.

How a DAST scan actually works

When you point a DAST scanner at your application, it typically goes through these phases:

1. Crawling / Discovery The scanner maps out your application. It follows links, submits forms, clicks buttons (modern DAST tools use headless browsers for JavaScript-heavy SPAs), and builds a sitemap of every endpoint it can find.

This is where a lot of DAST scans go sideways, honestly. If the crawler can’t reach a page — maybe it’s behind a multi-step wizard, or it requires a specific sequence of API calls — the scanner won’t test it. You don’t know what you don’t test.

2. Attack simulation For each discovered endpoint, the scanner sends malicious payloads. SQL injection strings in form fields. XSS payloads in URL parameters. Path traversal sequences in file upload names. Malformed headers. Oversized inputs.

Here’s a simplified example of what the scanner does for a login form:

POST /login HTTP/1.1
Host: your-app.example.com
Content-Type: application/x-www-form-urlencoded

username=admin' OR '1'='1&password=anything

If the response comes back with a 200 OK and a valid session cookie, that’s a confirmed SQL injection. The scanner flags it.

3. Response analysis The scanner examines responses for signs of vulnerability. This includes:

• Error messages that leak stack traces or database details
• Reflected input that isn’t properly encoded (XSS)
• Missing security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security)
• Open redirects following attacker-controlled URLs
• Information disclosure in response bodies or headers

4. Authentication testing Good DAST tools will test authenticated functionality too. You provide credentials or a session token, and the scanner tests everything behind the login. This matters because most of the interesting attack surface is in authenticated areas. An unauthenticated DAST scan barely scratches the surface.

What DAST catches that SAST can’t

We get asked this a lot — “why do we need DAST if we already run SAST?” Fair question. Here’s the honest answer.

Server and infrastructure misconfigurations

SAST looks at your code. But your application doesn’t run in a vacuum — it sits on a web server, behind a load balancer, maybe with a WAF in front. DAST tests the entire stack:

• TLS configuration (weak ciphers, expired certs, HSTS missing)
• Server version disclosure (that Server: Apache/2.4.41 header is giving attackers free recon)
• Default credentials on admin panels
• Directory listing enabled
• Backup files accessible (.bak, .old, web.config.bak)

Your code might be perfectly secure, but if nginx is misconfigured to serve your .env file, you’ve got a problem that only DAST will find.

Runtime behavior bugs

Some vulnerabilities only manifest at runtime. A classic example: race conditions in financial transactions. Your code looks fine in a code review — there’s a balance check before the debit. But if two requests hit simultaneously, both pass the check before either debit completes, and you’ve got a double-spend bug.

DAST tools that support concurrent request testing can catch these.

Authentication and session management

DAST excels here because it can actually test session behavior:

• Are session tokens sufficiently random?
• Do sessions expire after inactivity?
• Is the session invalidated server-side after logout? (You’d be surprised how often it isn’t.)
• Can you fixate a session by setting a known session ID?
• Are cookies marked Secure and HttpOnly?

CVE-2023-44487 (the HTTP/2 Rapid Reset attack) is a good example of a vulnerability that SAST couldn’t have found — it was a protocol-level issue in how servers handled stream cancellation. You had to actually send HTTP/2 frames to discover it.

CORS misconfigurations

Your code might set CORS headers correctly in theory, but DAST tests what the server actually returns:

GET /api/user/profile HTTP/1.1
Host: your-app.example.com
Origin: https://evil-attacker.com

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://evil-attacker.com
Access-Control-Allow-Credentials: true

If your app reflects arbitrary origins with credentials allowed, that’s a real vulnerability — and DAST finds it by trying.

DAST for modern applications

The old complaint about DAST — “it doesn’t work with single-page applications” — used to be valid. Traditional DAST scanners made HTTP requests and parsed HTML responses. When the entire UI is rendered client-side by React or Angular, there’s no HTML to parse.

Modern DAST tools have caught up. They use headless browsers (Chromium, usually) to render JavaScript, interact with SPAs, and test API endpoints directly. Offensive360’s DAST engine, for example, handles JavaScript-heavy applications by actually executing the client-side code and interacting with the rendered DOM.

API security testing

This is where DAST has really evolved. Most modern applications aren’t just web UIs — they’re APIs consumed by mobile apps, SPAs, partner integrations, and internal microservices.

DAST tools can now import OpenAPI/Swagger specs, Postman collections, or GraphQL schemas to understand your API surface. Then they test:

• Broken Object Level Authorization (BOLA) — Can user A access user B’s resources by changing an ID parameter? This is A01 in the OWASP API Security Top 10, and it’s everywhere.
• Mass assignment — Sending extra fields in JSON bodies that the API shouldn’t accept
• Rate limiting — Brute-forcing endpoints that should be throttled
• Input validation — Sending unexpected types, oversized payloads, or special characters

Here’s what a BOLA test looks like in practice. Say your API has this endpoint:

GET /api/v1/orders/12345
Authorization: Bearer eyJhbG...  (User A's token)

The DAST tool will try:

GET /api/v1/orders/12346
Authorization: Bearer eyJhbG...  (same User A's token, different order ID)

If it gets back User B’s order data, that’s a BOLA finding. Simple in concept, devastating in impact. We’ve seen this in production APIs at major companies.

Setting up DAST in your pipeline

DAST needs a running instance of your application to test against. This makes CI/CD integration slightly more involved than SAST (which just needs source code), but it’s very doable.

The typical setup:

# .github/workflows/dast.yml
name: DAST Scan
on:
  pull_request:
    branches: [main]

jobs:
  dast:
    runs-on: ubuntu-latest
    services:
      app:
        image: your-app:${{ github.sha }}
        ports:
          - 8080:8080
        env:
          DATABASE_URL: postgresql://test:test@postgres:5432/testdb
      postgres:
        image: postgres:15
        env:
          POSTGRES_DB: testdb
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test

    steps:
      - name: Wait for app to start
        run: |
          timeout 60 bash -c 'until curl -s http://localhost:8080/health; do sleep 2; done'

      - name: Run DAST scan
        run: |
          o360 dast --target http://localhost:8080 \
            --auth-url http://localhost:8080/login \
            --auth-username test@example.com \
            --auth-password testpass123 \
            --format sarif \
            --output dast-results.sarif

      - name: Upload results
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: dast-results.sarif

A few things to watch out for:

Use a dedicated test environment. Never point DAST at production unless you’re specifically doing a production security test with proper change management. DAST scanners submit forms, create accounts, and generally make a mess. We’ve seen DAST scans accidentally trigger password resets for every user in a staging database.

Seed test data. DAST works better when there’s data to work with. An empty database means the scanner can’t test data access controls, search functionality, or export features.

Authenticate the scanner. An unauthenticated scan covers maybe 20% of your attack surface. Give the scanner valid credentials — preferably multiple accounts with different roles so it can test privilege escalation.

DAST vs. SAST — which one do you need?

Both. Sorry, but that’s the real answer.

We’ve written a detailed comparison of SAST vs DAST if you want the full breakdown, but the short version:

	SAST	DAST
Tests	Source code	Running application
Finds	Code-level bugs	Runtime & config issues
Speed	Fast (minutes)	Slower (30min-hours)
False positives	More	Fewer (confirmed by testing)
Coverage	All code paths	Only reachable paths
Language dependent	Yes	No

SAST catches things early when they’re cheap to fix. DAST validates that your application is actually secure when deployed. They overlap on some findings (XSS, injection) but each catches things the other misses.

The Verizon 2023 Data Breach Investigations Report found that web applications were involved in 26% of breaches. Of those, the split between code-level vulnerabilities (SAST territory) and configuration/runtime issues (DAST territory) was roughly even. Dropping either one leaves a gap.

Offensive360 offers both SAST and DAST in a single platform, which means findings from both tools are correlated and deduplicated. When SAST finds a potential SQL injection in your code and DAST confirms it’s exploitable in the running application, that finding gets bumped to the top of your triage queue. That correlation is genuinely useful — it turns “this might be a problem” into “this is definitely a problem, here’s the proof.”

Practical advice from our testing

A few things we’ve learned running DAST at scale:

Start with passive scanning. Most DAST tools have a passive mode that just observes traffic without sending malicious payloads. Run this first to catch low-hanging fruit like missing headers, cookie flags, and information disclosure. It’s fast and non-destructive.

Scope your scans carefully. DAST crawlers will follow links wherever they lead. If your app links to a third-party service, the scanner might start testing that service. Scope your scan to your own domains. (Also: definitely don’t accidentally DAST scan your production payment processor. Speaking from someone else’s experience here.)

Schedule full scans weekly, not just on PRs. Infrastructure changes, certificate renewals, server updates — these can introduce vulnerabilities without any code changes. A weekly full scan catches drift.

Fix header issues first. Missing Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security — these take five minutes to fix in your web server config and eliminate a whole category of findings from your report. Quick wins.

The key takeaway: DAST tests your application the way an attacker would. If you’re only doing code review and SAST, you’re testing the blueprints but never actually trying to pick the lock. Do both.