DAST Scanning

What DAST does (and what it doesn't)

DAST tests your application from the outside. It doesn't look at your source code, your container image, or your dependency manifest — it just makes HTTP requests, observes responses, and decides whether something exploitable lives behind those responses. It catches the issues an attacker actually exploits in production: SQLi, XSS, SSRF, authentication and session flaws, broken access control, misconfigurations.

DAST does NOT catch issues that are invisible at the network boundary — secrets in your git repo (use Secrets Scanning), vulnerable dependencies that aren't reachable from the public surface (use SCA), or code-level bugs in non-deployed paths (use SAST). Run all three; each one covers what the others miss.

How a Sectora scan works

A scan is five phases:

1. Pre-flight. Verify the target is reachable, the domain is on file (you own it), and authentication (if configured) works.
2. Crawl. Discover URLs starting from your target. Uses HTTP for traditional sites and headless Chromium (Playwright) for JavaScript-rendered SPAs.
3. Fingerprint. Identify the technologies your site uses (framework, server, CDN, JavaScript libraries) so the engine runs only the relevant checks instead of all 8,000 templates against every endpoint.
4. Test. Run the security checks — Nuclei templates, custom payloads, SSL/TLS analysis, header analysis, API-specific tests, LLM/MCP prompt injection (for AI endpoints), and the chain engine for multi-step attack flows.
5. Triage. The AI false-positive analyzer reviews each finding, attaches an exploit-confidence score, and (if you opted in) auto-creates tickets in your linked tracker.

Scan profiles

Pick a profile in the New Scan dialog → step 2. Profiles control which checks run, not how aggressively they run; aggression is set independently via the noise slider below.

Configurable options (every field, what it does)

Step 1 of the New Scan dialog exposes these. Defaults are sensible — read this section before you change anything in production.

Target URL

The starting point for the crawl. Sectora restricts scanning to the same registrable domain — a scan of https://app.example.com will not follow links to https://other.com. To scan multiple subdomains, create one scan per origin or use scheduled scans with a target list.

Max Depth

How many link-hops the crawler walks from the target URL. Default 3 covers most sites: target → menu → page → subpage. Use 5–10 for documentation-heavy sites; lower (2) for tightly-scoped APIs where deep crawls just rediscover the same handlers.

Timeout (sec)

Hard ceiling on total scan time. The scanner exits cleanly when reached and reports whatever it found. Default 1800 (30 min). Bump to 3600+ for Full profile on large sites. The pre-deploy gate in CI usually wants 300 (5 min) max.

Headless Mode (SPA Support)

Toggles between HTTP-only crawling and headless Chromium (Playwright). Enable for React/Vue/Angular SPAs where the initial HTML is mostly empty — without this the crawler sees only the JavaScript bundle URL and walks no further. Costs ~3-5× more time and CPU but is mandatory for SPAs.

Client-side security scanning (beta)

When enabled (only effective with Headless Mode), the DOM analyzer extracts every <script> tag, every fetch() call, and every window.eval usage during page render. Detects DOM XSS sinks, source-map exposure, and prototype-pollution paths the server-side crawl can never see.

Saved CVE / CWE List + Target CVEs

Narrow the scan to a specific list of CVEs or CWE categories. Useful when an advisory drops (e.g. CVE-2024-3094) and you want a fleet-wide "are we vulnerable" check in minutes, not hours. Saved lists live at Settings → CVE Lists; you can also paste a one-off list in the Target CVEs field.

Product / Technology Hints

Tell the scanner what stack you run (e.g. wordpress, php, mysql). The Nuclei template selector filters to templates that match those technologies, cutting scan time 30–50% with no loss in coverage for the stack you actually have. Tech fingerprinting catches what you don't list, so this is purely an accelerator.

Noise / Aggression slider

Three positions, controlling how aggressive each check is:

• Precise (0.1). Only fire payloads with high confidence of being real. Lowest false-positive rate, highest false-negative rate. The default for production scans.
• Balanced (0.5). Default for staging. Fires medium-confidence payloads too.
• Comprehensive (0.9). Fire everything, including timing-based blind-SQLi probes and OOB DNS callbacks. Use on staging/dev with realistic data, never production — it produces low-confidence findings that need manual triage.

Max Requests / Host + Concurrent Hosts

Rate controls. Max Requests/Host caps requests-per-second to a single hostname (default 50/s — safe for most production targets). Concurrent Hosts is for multi-target scans (default 4). If your origin is fronted by Cloudflare or another WAF, lower these to avoid being rate-limited or blocked mid-scan.

Auto-create tickets

When enabled, every finding above your configured severity threshold (default High and above) becomes a ticket in your linked Jira / Linear / GitHub Issues. Ticket includes the URL, reproduction request, attack payload, fix suggestion, and a link back to the Sectora finding for one-click verify-fix later.

What gets tested

The engine is module-based. Below is everything that runs at least in the Full profile; subsets run at OWASP Top 10 and Quick.

API security testing

APIs are a different beast — they don't have a homepage to crawl from. Use the API Scan dialog (separate from the standard DAST flow) to feed in an OpenAPI/Swagger spec, a Postman collection, or a base URL + auth profile. Sectora enumerates endpoints from the spec, fuzzes parameters per OWASP API Top 10 (broken object-level authorization, mass assignment, excessive data exposure, rate limiting, etc.), and runs auth-bypass attempts (JWT alg:none, expired tokens, token substitution between users).

See API Security for the dedicated guide. Same Nuclei + chain engine underneath; different driver.

Authenticated API testing — automatic from a web scan

You don't need the separate API Scan dialog to test your API. When you run a normal DAST scan with a session, Sectora renders the app as the logged-in user, captures the real XHR/fetch calls your single-page app makes behind login, and runs the OWASP API Top 10 suite against those exact endpoints — IDOR/BOLA, broken authentication, mass assignment, and injection on the real request shapes. This is the difference between "your site is missing a CSP header" and "GET /api/orders/{id}returns another tenant's order."

By default this runs read-only (safe GET/HEAD tests only). To enable write-method tests (mass assignment, injection) against your own app, choose Active mode in the scan form and confirm the ownership acknowledgement — active testing never runs without it.

Behind a WAF? The API tests present a consistent real-browser identity (and can route through a residential proxy via the scan’s Proxy settings) so a WAF like Cloudflare is less likely to fingerprint and block them. If a WAF still blocks a meaningful share of requests, the scan surfaces a “Scan coverage incomplete — N% of requests blocked by WAF” advisory so you know the result is partial. A WAF blocking the scanner doesn’t mean your app is safe — it means the scanner couldn’t reach the endpoints to test them. For full coverage on your own app, allowlist Sectora’s scanner IP — every scan egresses from one static IP shown under Settings → Scanning; add an allow rule for it in your WAF (Cloudflare/AWS WAF/Akamai). See Scanning a site behind a WAF for the per-WAF allowlist steps (Cloudflare/AWS WAF/Akamai). (Routing through the scan’s residential-proxy option is the fallback when you can’t allowlist by IP.)

Broken access control & IDOR

On every authenticated scan, Sectora replays each captured read with no session and flags any that still return the protected data — broken access control / missing authentication, double-confirmed. Supply a second, low-privilege identity(paste user B's auth headers in the scan form) and Sectora also replays object-scoped reads as that user, flagging any that return the first user's data — real IDOR / broken object-level authorization. Findings are evidence-backed ("this exact object is returned to a different user"), and the second identity's credentials are encrypted at rest.

AI endpoint scanning

Newer than the rest of the engine — covers attack surface the public Semgrep / Nuclei ecosystem hasn't indexed yet:

• LLM-backed endpoints. If your API returns LLM-generated text, the LLM scanner sends prompt-injection payloads (ignore previous instructions, instruction-leak, role-hijack, jailbreaks from a curated payload set updated weekly). Findings include the exact payload and the model's response.
• MCP servers. If you expose a Model Context Protocol server, the MCP scanner enumerates tools and probes for unsanitized inputs flowing into filesystem / shell / network sinks — the same class of bug we caught in our own integrations.

Authenticated scanning

Most real vulnerabilities live behind login. Sectora ships four auth strategies, configured in step 3 of the New Scan dialog:

• Form login (cookie-based) — classic POST with auto CSRF discovery.
• OAuth 2 / OIDC (Bearer token) — uses a saved AuthProfile to mint tokens.
• SAML — coming soon (Phase 4).
• Recorded login — coming soon (Phase 4); replays a Chromium recording for the few cases where form-based + OAuth2 don't cover the flow.

Full setup guide for each is at Authenticated DAST Scanning. Critical detail: always set the Auth verify URL for scans longer than your session lifetime, otherwise the back half of the scan runs unauthenticated without warning.

Verify-fix re-scan

Once a developer claims a fix is shipped, click the green ✓ shield icon next to any finding. Sectora replays the original exploit request — same payload, parameter, method, auth context — and tells you whether the issue still triggers.

• Fixed — the payload no longer reflects in the response, or the endpoint now returns 401/403/404. verified_fixed_at is stamped on the finding.
• Still exploitable — the payload still triggers. The finding stays open; the attempt is logged in last_verification_details with the response diff so you can see why.
• Error — Sectora couldn't reach the target. Most common cause: target is down or DNS-cached. Try again.

API: POST /api/v1/vulnerabilities/:id/verify. Returns the full comparison so CI can gate on it (e.g. "PR can't merge until verify-fix says Fixed").

Auto Virtual Patching with Shield

From any DAST finding, click Virtual-patch. Sectora generates a Shield WAF rule that blocks the exact request shape (URL + method + parameter + payload signature) that triggered the finding. Deploy globally in <30 seconds. Full mechanics: Auto Virtual Patching.

Scheduled + CI/CD integration

Two operating modes for hands-off scanning:

Scheduled scans

Configure at Scans → New schedule. Cron syntax, multi-target support, per-schedule profile + auth + alert policy. Set up daily Quick scans on every public origin + weekly Full on staging as a baseline.

CI/CD gate

Block PRs that introduce new High/Critical findings:

# GitHub Actions example
- name: Sectora DAST scan
  run: |
    SCAN_ID=$(curl -sf -X POST \
      -H "Authorization: Bearer ${{ secrets.SECTORA_API_KEY }}" \
      -H "Content-Type: application/json" \
      -d '{"target_url":"https://staging.example.com","scan_type":"quick"}' \
      https://api.sectora.io/api/v1/scans | jq -r .id)

    # Poll until complete (max 10 min)
    for i in {1..60}; do
      STATUS=$(curl -sf -H "Authorization: Bearer ${{ secrets.SECTORA_API_KEY }}" \
        https://api.sectora.io/api/v1/scans/$SCAN_ID | jq -r .status)
      [ "$STATUS" = "completed" ] && break
      [ "$STATUS" = "failed" ] && exit 1
      sleep 10
    done

    # Fail the PR if any High+ findings are NEW (not seen on main)
    curl -sf -H "Authorization: Bearer ${{ secrets.SECTORA_API_KEY }}" \
      "https://api.sectora.io/api/v1/scans/$SCAN_ID/diff?baseline=main&min_severity=high" \
      | jq -e '.new | length == 0'

See PR Gates for the full template + how to wire it into branch protection.

Troubleshooting

"No findings, but I know there are bugs"

• Run the same target with Comprehensive noise — Precise mode skips medium-confidence payloads.
• Verify authentication actually works by checking the Auth verify URL result in the scan logs.
• If your app is an SPA, enable Headless Mode — the HTTP crawler sees ~3 URLs on a typical React site.
• Check that your target URL isn't behind a WAF blocking Sectora. Allowlist our scanner's static egress IP (shown under Settings → Scanning) in your WAF, or use a staging origin that bypasses the WAF.

"Scan failed with rate-limit / 429 errors"

• Lower Max Requests/Host from 50 to 10–20.
• If you can, scan a staging origin or a Cloudflare-bypass DNS record (origin-only) that doesn't go through the WAF.
• For self-hosted targets, allowlist the scanner's single static egress IP (Settings → Scanning) at your WAF.

"Scan reports way too many findings"

• You're probably on Comprehensive noise on a non-prod environment with dev errors enabled. Flip to Balanced or Precise.
• Enable AI Smart Triage in Settings → AI; it'll downgrade findings where it identifies a mitigation in the response.
• Add Product Hints — Nuclei runs templates that don't apply to your stack otherwise.

"How do I know if the scan ran authenticated?"

Open the scan detail page → Coverage tab. The "authenticated requests" counter should be greater than zero. If it's zero, either the login flow failed or the Auth verify URL was missing. Check the scan logs for [auth-session] entries.

Comparison to Burp / Invicti / Acunetix

All four are capable DAST tools. Where Sectora differs:

• One-click virtual patch. Confirm a finding → deploy a Shield WAF rule in 30 seconds. No competitor ships an integrated WAF; you'd need to hand-write the rule for ModSecurity / Cloudflare and hope it's right.
• AI Smart Triage. Every finding gets an AI verdict + confidence score, downgrading mitigations the static rule can't see. Cuts triage time roughly 5×.
• LLM + MCP scanning. Prompt-injection + agent-tool sandbox detection. No major DAST has shipped equivalents yet.
• Chain engine. Multi-step attack flows (e.g. IDOR enumeration → privilege escalation → data export) where pure single-request scanners miss the chain.
• Verify-fix re-scan API. Wire into CI: PR can't merge until the original exploit no longer triggers.
• Pricing. Per-target instead of per-seat; we don't paywall the API or the integrations.

What's next

• Set up your first scan: Quick Start walks you through it in 5 minutes.
• Wire scans into CI: PR Gates.
• Scan APIs: API Security.
• Lock down with virtual patches: Auto Virtual Patching.
• Authenticate the scan: Authenticated DAST Scanning.