Legacy DAST
Crawl first, then run a fixed list of checks against whatever the crawl happened to find. One pass, no plan, and a report that hands you a severity and leaves the verification to you.
Technical capabilities
From crawl to confirmed finding.
Crawl, two-factor auth, deterministic attack modules, an agent loop, browser-verified confirmation, out-of-band proof, Android capture and risk-ordered reporting — every capability on one page.
Continuous loop · crawl and attack share one queue
- 01 Discover The browser-driven crawler renders the target, maintains authenticated state and adds newly observed routes to a shared queue.
- 02 Attack Deterministic modules and adaptive evasion test the live surface while the crawl continues; when a check stalls, the agent loop proposes the next experiment and the engine runs it.
- 03 Confirm Timing differentials, browser proof and out-of-band callbacks promote a finding from Possible to Confirmed — or refute it outright.
- 04 Export The local findings database produces HTML, JSON and Markdown reports, SARIF 2.1.0 for GitHub code scanning and a MITRE ATT&CK Navigator layer, without uploading the report to the account site.
Not a checklist — a continuous loop
Follow the complete testing path: authenticated crawl past two-factor walls, Android app capture, recon, deterministic attack modules, adaptive evasion, an agent loop for the checks that stall, out-of-band proof, browser-verified confirmation and reports that order the queue for you.
SelfSec — hybrid agentic DAST
Crawl and attack share a queue, an agent loop proposes the next experiment from what the engine actually observed, and a finding carries the stage it earned — Possible until independent evidence promotes it, Exploited only when impact was actually demonstrated.
A crawler that renders like a human, not a bot
Humanized, browser-driven crawling
A Chromium-backed crawler renders JavaScript-heavy apps, captures browser-evolved cookies and dedupes by content fingerprint. In-page probes go further: Blazor circuit detection with lazy-assembly fetching, React Server Components and Web Components recon, import-map and SystemJS resolution, HTMX endpoint capture, IndexedDB and storage harvesting, postMessage interception and source-map discovery. When a bot wall or CAPTCHA stops the crawl, it does not fail the run — the live browser session is streamed to you, you solve the challenge by hand, and the scan carries on from where it stopped.
Crawl · representative output
bot wall hit → live browser streamed to you → scan resumes
Blazor circuitsReact Server Componentsimport mapsHTMX
3 more
IndexedDBpostMessageCAPTCHA hand-off
Every contract you already publish becomes a target list
Point the scanner at an OpenAPI or Swagger document, a WSDL, a GraphQL endpoint or a tRPC router and it reads the schema instead of guessing at it — operations, parameters, content types and nested body shapes all become typed injection points. Postman collections and HAR captures import the same way. Undocumented surface is recovered too: JavaScript chunk extraction, source-map recovery, meta-framework route discovery for Next, Nuxt and SvelteKit, module federation, PWA manifests, .well-known endpoints and Spring Actuator.
Crawl · representative output
schema read, not guessed — typed parameters become typed injection points
OpenAPIWSDL / SOAPGraphQL introspectiontRPC
3 more
PostmanHARsource maps
Application-layer recon and CVE matching
Real targets run on real products. SelfSec fingerprints WordPress, Drupal, Joomla, Magento, Sitefinity, Telerik and Kendo UI with user, plugin, theme and module enumeration, detects SPA, Blazor and Web Component frameworks, and matches discovered versions against known CVEs. Discovery sweeps cover admin panels, sensitive files, exposed source control, sitemaps and Wayback-seeded historical URLs; CDN-fronted origin IPs are recovered from Certificate Transparency, DNS and CDN range filtering.
Crawl · representative output
WordPress 6.4 · 3 plugins → 2 CVEs matched · origin IP recovered behind the CDN
WordPressDrupalJoomlaMagento
3 more
SitefinityTelerikKendo UI
WebSocket endpoints are first-class targets
The crawler captures live WebSocket frames, and protocol-aware framing — JSON, Socket.IO, GraphQL-WS, STOMP, SignalR and raw — decodes them into injectable sites that flow into the same attack workers as HTTP. A ws_login handshake authenticates the socket, and a CSWSH probe checks whether the handshake actually enforces Origin.
Crawl · representative output
CSWSH probe — is Origin actually enforced?
JSONSocket.IOGraphQL-WSSTOMP
2 more
SignalRraw
Two-factor logins are a configuration, not a blocker
The login wall most scanners stop at
Give the scanner a TOTP secret and it derives the one-time code itself on every login, so a two-factor application is scanned behind the wall rather than at the front door. Multi-step logins that split identifier and password across screens are handled, and an OIDC configuration goes further: point it at the discovery document with a refresh token and it mints and silently renews its own access token for the length of the scan. Bearer tokens, cookie strings, HTTP Basic and arbitrary custom headers cover everything else, including a WebSocket authentication frame template for sockets that authenticate separately from the page.
Auth · representative output
TOTP secret in, one-time code derived per login — no manual step
TOTP 2FAMulti-step loginOIDC refresh flowBearer
3 more
CookieHTTP BasicWebSocket auth frame
A session that survives the whole scan
Authenticated crawls fail in a specific and quiet way: the session dies partway through and the rest of the run silently tests the logged-out application. SelfSec re-validates the session as the crawl progresses and re-authenticates when it has lapsed, avoids logout links by default so the crawler does not end its own session, and keeps a CSRF token jar so state-changing forms are submitted with a token the application will accept.
Auth · representative output
session lapses → re-authenticated mid-crawl, not silently degraded
Periodic session re-checkAutomatic re-loginLogout avoidanceCSRF token jar
An attack engine that thinks, not a checklist
Attack · engine readout
- Active modules
- 21
- Database engines
- 19
- Evasion techniques
- 42
Vulnerability modules
SQL InjectionXSSRCECommand InjectionSSRFXXESSTIInsecure Deserialization
13 more
Path TraversalNoSQL InjectionLDAP InjectionGraphQLCRLF InjectionHost Header InjectionCORS MisconfigurationOpen RedirectAccess Control BypassJWT AttackRequest SmugglingPrototype PollutionWeb Cache Deception
Database engines
MySQL/MariaDBPostgreSQLMSSQLOracleSQLiteDB2SnowflakeClickHouse
11 more
FirebirdSAP HANARedshiftDuckDBSparkSybaseInformixSAP MaxDBMicrosoft AccessH2HSQLDB
A SQL injection sub-engine, not a checkbox
Fingerprints the engine behind the injection point across 19 database families — from MySQL/MariaDB, PostgreSQL, MSSQL and Oracle through to Snowflake, ClickHouse, SAP HANA and Sybase — then runs error, boolean-blind, time-based, union, stacked, second-order and out-of-band techniques with payload sets written per engine rather than shared. On a confirmed hit it switches from detection to demonstration: automated extraction across 4 blind-exfiltration strategies, plus schema and data dumping, credential and privilege enumeration, and — where the engine and permissions actually allow it — file read and write.
Attack · representative output
fingerprint → technique → extract · 4 blind-exfiltration strategies
errorboolean-blindtime-basedunion
3 more
stackedsecond-orderout-of-band
The bugs a 2015-era scanner never looks for
Injection is table stakes. The modules that separate a serious scanner from a checklist are the ones testing how your stack disagrees with itself: HTTP request smuggling over raw sockets and HTTP/2 clients (CL.TE, TE.CL and CL.0), web cache deception and cache poisoning verified through a real cache-hit oracle rather than a guess, prototype pollution, and a JWT attack suite that tries algorithm confusion, the none algorithm, JWK header injection and offline secret cracking against the tokens your app issued.
Attack · representative output
cache attacks require a real cache-hit indicator on the second request
CL.TE / TE.CL / CL.0Web cache deceptionCache poisoningPrototype pollution
2 more
JWT alg confusionJWK injection
Broken access control, tested like an attacker would
The most common critical finding in real applications is also the hardest to automate honestly, because a scanner that shouts on every 200 is worse than useless. SelfSec takes a live 403 baseline, generates a random sibling path as a 404 negative control, then works through path mutations, X-Original-URL and X-Rewrite-URL rewriting, forwarded-identity headers and HTTP verb switching. A bypass is only reported when the response diverges materially from both controls and is not a WAF block, a login redirect or a throttle in disguise.
Attack · representative output
must diverge from both controls — and not be a WAF page wearing a 200
403 baseline404 negative controlPath mutationHeader rewritingVerb switching
AI that plans the attack, the engine that confirms it
Orchestrator
- 01 · Deterministic engine
Hardcoded modules do the testing
Fixed payload sets, a SQL injection engine with per-database techniques, a Chromium crawler that keeps authenticated state, and a WAF evasion chain composed per target. Every request is repeatable and every verdict is auditable.
- 21 active vulnerability modules plus passive analyzers
- Timing baselines and differential testing instead of payload echo
- Runs unchanged with AI switched off
crawl → attack → observe · the same engine, with or without a model
- 02 · Agent loop
The model plans the next experiment
When a deterministic check stalls, the model is handed the real crawl data and findings, proposes the next experiment, watches the result and plans again — inside a turn cap and a per-run budget. It never sends a request itself; the engine executes what it proposes.
- Plan, call a tool, observe, iterate — bounded rounds, bounded experiments
- Tools it can call: single probe, module sweep, WAF mutation, intruder run, response compare
- Narrow helper modes for stuck checks: WAF bypass, boolean-blind oracle, XSS context breakout, login selector synthesis
dangerous actions wait for your approval · suggest or autonomous mode, your choice
- 03 · Verification gate
The engine decides what is real
Model text never confirms anything. A candidate the agent reports is recorded as Possible and handed to the same confirmation workers as every other finding. The model can nudge a confidence score only inside a narrow band, and it keeps no memory between scans.
- report_finding records a candidate, not a Confirmed finding
- Deterministic reproduction before Possible becomes Confirmed
- Provenance recorded on every AI-assisted finding
no alert() → not Confirmed · no reproduction → not Confirmed, however good the proposal looked
Provider-pluggable, budgeted AI
Bring your own OpenAI or Anthropic key, or run entirely offline with Ollama. Beyond proposing context-aware payloads and rescoring ambiguous findings inside the confidence band, the model drives a post-scan adaptive attack phase: it reads the scan graph, plans a targeted attack and an ad-hoc module executes it step by step — while the classical engine still owns the final verdict, so nothing ships hallucinated. A hard per-run budget cap — $1 by default — and a token-bucket limiter mean AI is never a single point of failure: every AI-assisted finding carries its provenance metadata, and with AI disabled the classical engine runs unchanged.
Agent · representative output
AI proposal → classical engine → confirmed · provenance per finding
OpenAIAnthropicOllama (offline)budget cap $1/runtoken-bucket limiter
The stage a finding earns, not the one it claims
The confirmation pass actively disagreed. The finding is kept with its evidence rather than silently dropped, so you can see what the engine decided and why.
Cross-site scripting confirmed by a browser, not a regex
Reflected payload matching produces the false positives DAST is famous for, because a payload appearing in a response body is not the same as a payload executing. SelfSec re-serves the candidate into a Chromium page it controls, hooks the dialog handler and waits. If no dialog fires, the finding does not reach Confirmed — no matter how clean the reflection looked.
Confirm · representative output
no alert() → not Confirmed, however good the reflection looked
Chromium re-executionDialog handlerReflection is not execution
Dedicated confirmation workers, not a second opinion from the same rule
After the attack phase, separate confirmation workers re-test the classes most prone to false positives — SQL injection, command injection, path traversal and NoSQL injection — with their own logic rather than a rerun of the rule that found them. A cross-technique sweep then looks at the surface as a whole, and weaker findings on a surface already explained by a stronger one are superseded instead of padding the count.
Confirm · representative output
four confirmation workers · weaker findings superseded, not stacked
Independent re-testCross-technique sweepSupersede duplicatesManual re-verify
The detection engine, demystified
Findings combine via noisy-OR confidence capped at 0.99 — rules reinforce each other but never stack to false certainty. Time-based detection takes a per-target median-and-standard-deviation baseline so network jitter never fakes a hit, an adaptive worker pool resizes on response-time and error-rate signals, and a 14-day host-level anomaly memory carries block-rate and status-bias signals across scans. Every finding keeps the raw request, the response and the baseline it was measured against, so the verdict is auditable rather than asserted.
Confirm · representative output
confidence = 1 − ∏(1 − pᵢ), capped at 0.99 — no false certainty
noisy-OR confidencemedian+stddev baselineadaptive workers14-day anomaly memory
Tests through the firewall you actually run
A 42-technique evasion chain, composed per target
209 fingerprint signatures identify 71 firewall and bot-management vendors, and the scanner then composes a chain from 42 evasion techniques at 4 intensity tiers from off to aggressive — HTTP/2 desync, request smuggling, UTF-16LE and UTF-7 charset differentials, inspection-size padding, cookie delimiter smuggling, GraphQL alias overload, parameter pollution and fragmentation, unicode homoglyph and best-fit mapping, and 2025-era SQLi, XSS, command-injection and SSTI mutations. The chain is assembled for the vendor in front of you, not fired blind.
WAF evasion · representative output
209 signatures → 71 vendors → chain composed per target
HTTP/2 desynccharset differentialsize paddingalias overload
2 more
param fragmentationhomoglyph
Cross-scan learning memory
A 30-day, host-level evasion memory records which techniques actually landed against each target and reorders the evasion chain by historical success before the next scan fires its first probe. The scanner gets sharper against a firewall every time you run it — adaptation a static signature list cannot do.
WAF evasion · representative output
the chain reorders itself before the first probe of the next scan
30-day evasion memorysuccess-ranked chainper-host learningreordered pre-scan
Heuristic mode for signatureless deployments
When no known vendor fingerprint matches, a baseline-aware classifier compares blocked-versus-allowed responses to detect a firewall by behavior alone, then escalates evasion against it — so a custom or in-house deployment is treated as a target, not a wall.
WAF evasion · representative output
no signature required — detected by how it blocks
baseline-awarebehavioral detectioncustom deploymentsauto-escalation
Or go around it entirely
Origin-IP discovery recovers the real server behind a CDN or filtering layer from Certificate Transparency logs, DNS records and CDN range filtering. When the origin answers directly, SelfSec scans it without the filtering layer ever seeing the traffic.
WAF evasion · representative output
CT logs + DNS → origin IP → scan behind the filter
Certificate TransparencyDNS recordsCDN range filteringorigin scan
Android apps feed the same engine, not a second product
Android traffic becomes attack surface
Point a scan at an APK or an installed package instead of a URL. The device is routed through a capture proxy on the loopback interface, the app is driven, and every request it sends is normalized into a discovered target for the same engine that tests a website — the same 21 vulnerability modules, the same confirmation logic, the same local findings database. Scope hosts keep the run on the backend you are authorized to test. Mobile here means Android; iOS is not supported.
Mobile · representative output
app request → capture proxy → the same attack workers as HTTP
APK or installed packageloopback capture proxyscope hosts21 vulnerability modules
The package is read before the app is driven
Static analysis decodes the package and runs the Android ruleset over the manifest and the decompiled code: debuggable and backup flags, cleartext traffic, trust-all trust managers and hostname verifiers, WebView JavaScript interfaces and SSL-error bypasses, user trust anchors in the network security config, ECB and DES ciphers, MD5 and SHA-1 hashing, insecure randomness, world-accessible storage, sensitive logging and hardcoded secrets. A structural pass adds exported components with no permission guard, providers that grant URI permissions, custom permissions with a weak protection level and an outdated minSdkVersion. Deeplinks recovered from the manifest are then fired at the running app, so the crawl reaches screens the UI driver never opens on its own.
Mobile · representative output
manifest deeplinks → fired at the running app → new captured traffic
manifest analysisWebViewTLS trustcrypto
3 more
storagehardcoded secretsdeeplinks
An emulator, or the phone on your desk
Boot a named virtual device, or reuse a device already connected over USB or wireless ADB pairing. An Appium-driven crawl walks the activities and fills login forms with the credentials you supply; when Appium or a JDK is missing the run falls back to enumerating and launching activities directly instead of failing. Split-APK installs are handled. The device proxy is journaled before it is changed, restored on teardown and reconciled at the next start if a run ends badly — the phone is left as it was found.
Mobile · representative output
proxy journaled before it changes · restored on teardown, reconciled on restart
virtual device bootwireless ADBAppium crawlactivity fallbacksplit APKs
HTTPS interception, and what it costs
On a rooted device an instrumentation server loads an unpinning script covering Conscrypt, SSLContext, OkHttp, WebView SSL errors, TrustKit and Appmattus, plus native BoringSSL verification — the path Flutter and NDK-pinned applications use. Without root, the package is decoded, a network security config that trusts the scanner's own certificate authority is written, the instrumentation gadget is embedded, and the app is rebuilt and re-signed. If neither path is available the scan still runs and says so: HTTPS coverage degrades to cleartext instead of quietly covering less.
Mobile · representative output
no root and no repackage → cleartext-only coverage, stated in the run
SSL unpinningBoringSSL / FlutterAPK repackagere-signeddeclared degradation
Triage and reporting that ships
Reports in the standards your tools already read
- CVSS 4.0
- vector on every CVE-bearing finding
- CISA KEV
- known-exploited flag
- EPSS
- exploitation probability
- SSVC
- decision per finding
- SARIF 2.1.0
- GitHub code scanning
- MITRE ATT&CK Navigator
- technique layer
The queue orders itself
A list sorted by severity tells you what is theoretically worst, not what to do on Monday. Every finding that carries a CVE is enriched with four things: a CVSS 4.0 base score and full vector, whether CISA lists it in the Known Exploited Vulnerabilities catalog, its FIRST EPSS probability of exploitation in the next thirty days, and an SSVC decision derived from those inputs together with how automatable the vector is. A medium that is being exploited in the wild outranks a high that never has been.
Reporting · representative output
KEV-listed · EPSS 0.87 · SSVC: act — ahead of an unexploited high
CVSS 4.0 vectorCISA KEVFIRST EPSSSSVC decision51 CWEs mapped
Triage that survives across scans
Token-level baseline-versus-injected diffs, persistent false-positive marking, single-payload retry through the live engine and a side-by-side compare dialog. A request and response workbench lets you edit and resend anything the scan touched and watch the answer come back, so verifying a finding by hand never means leaving for another tool. Cross-scan global findings and an asset inventory roll every scan you have run into one view.
Reporting · representative output
edit the request, resend it, read the response — without leaving the scan
token-level difffalse-positive markingrequest workbenchglobal findingsasset inventory
Long scans that survive real life
A scan checkpoints as it goes: pause it, resume it, and if the host restarts mid-run it picks up from the checkpoint instead of starting over. Rescans can be incremental — pages whose content hash has not moved since a baseline run are skipped so the attack budget goes to what actually changed. Reports export as HTML, JSON, Markdown, SARIF 2.1.0 for GitHub code scanning and a MITRE ATT&CK Navigator layer, and scans are driven by a local HTTP API on 127.0.0.1 when you want to script them.
Reporting · representative output
SARIF 2.1.0 → GitHub code scanning, from a local API you can script
HTMLJSONMarkdownSARIF 2.1.0
2 more
ATT&CK Navigatorlocal HTTP API
Self-host
Know where every security-sensitive flow goes
Targets, responses and findings remain with the scanner. Activation is narrowly scoped: which device holds which plan, and nothing else.
Data boundary · local core · explicit remote flows
- Role
- Offense
- What it covers
- Web and Android apps
- When it works
- Before release and on demand
- Primary output
- Confirmed findings
- Runs on
- Windows or Linux host
- Data boundary
- Scan processing and findings stay local
Local processing with explicit data boundaries
Crawling, payload execution, responses and the findings database remain on the machine running SelfSec. Activation sends only the device identifier and your plan; the product reports no diagnostics. AI-assisted analysis can remain on your host through a locally configured runtime.
Self-host · representative output
core scan processing and findings remain on your host
Runs on 127.0.0.1Local findings databaseNo product telemetryOffline AI option
How SelfSec compares
Product model, deployment and buying path, in each vendor's own words
Acunetix is now sold as Invicti Web + API; the two right-hand columns describe one vendor's two products.
| Axis | SelfSec | Burp Suite Pro | Invicti | Invicti Web + APIformerly Acunetix |
|---|---|---|---|---|
| Buying basis | One flat plan at a published launch price, up to five devices. Nothing is charged during pre-release. Sold to businesses and self-employed professionals only.S | $4991 · Licensed for individual users. | Start a quote2 · on every tier; the only published figure is "$500 max per pentest" | Get a quote3 · A target is defined in Invicti as a fully qualified domain name (FQDN). |
| Deployment | Runs on 127.0.0.1 on a Windows or Linux host you control.S | Local installation only.4 | SaaS, on-prem, and hybrid options5 · the pricing page lists "On-Premises (coming soon)" for Web + API | deploy Invicti on premises or as a SaaS solution6 · the pricing page lists "On-Premises (coming soon)" |
| Validation approach | A finding stays Possible until independent evidence promotes it to Confirmed; Exploited only when impact is demonstrated; Refuted findings are kept with their evidence.S | Not stated on page7 | Proven exploitability. Zero guesswork.5 | automated proof of exploit for many findings6 |
| AI role | Optional and off by default. The agent proposes the next experiment; the engine runs it and decides. Your own Anthropic or OpenAI key, Ollama on your host, or the plan's hosted AI.S | AI assistance that helps you move faster through validation, exploration, and repetitive tasks, while keeping you in control.8 | Meet Octo, the hybrid agentic pentester combining scanners and AI9 | World's best DAST, even better with AI10 |
| Trial path | Join the launch list. Today the app runs only with an active plan. Launch evaluation terms are being decided and will be stated on this row before public downloads open.S | Try Burp Suite Professional for free8 | proof-of-concept licenses so you can evaluate the platform2 | no-risk Proof of Concept licenses3 |
| Exports and CI | HTML, JSON, Markdown, SARIF 2.1.0 and a MITRE ATT&CK Navigator layer, driven by a local HTTP API. A packaged command-line runner is on the roadmap.S | Simple reporting with automated report generation7 · formats: not stated on page | 110+ out-of-the-box integrations plus a powerful API and open-source CLI5 · formats: not stated on page | Integration with CI/CD pipelines6 · formats: not stated on page |
| Data boundary | Targets, responses and the findings database stay on the scanner host. Activation sends only the device identifier and your plan; the product reports no diagnostics; a configured AI service receives the scan context the work needs.S | Automatically keep a persistent log of all your testing activities using project files7 · where data is processed: not stated on page | Not stated on page2 · hosting regions are published; which data leaves your environment is not | Not stated on page6 |
| Team model | Up to five devices under one flat price, no per-user fees. Unlimited targets and scans.S | Designed for use by individual testers.4 | Unlimited users and scans5 | supports both small teams and enterprise security programs6 |
| Product model | Hybrid agentic vulnerability scanner (DAST) that runs as a self-hosted local service. Pre-release.S | The world's #1 web penetration testing toolkit.8 | Complete AppSec in one platform.11 | Acunetix is now Invicti Web + API.10 |
Sources · checked
“S” markers link to the SelfSec page that states the fact. This compares product models and buying paths, not detection results. Quoted text is copied from the linked page as it read on the checked date. “Not stated on page” means the linked page does not say; it does not mean the product lacks it. Vendor offerings and prices change; follow each source before purchasing.
Sources (11)
- https://portswigger.net/buy/pro (opens in a new tab)
- https://www.invicti.com/pricing (opens in a new tab)
- https://www.acunetix.com/pricing/ (opens in a new tab)
- https://portswigger.net/burp/dast/resources/dast-vs-professional (opens in a new tab)
- https://www.invicti.com/product/dast (opens in a new tab)
- https://www.acunetix.com/vulnerability-scanner/ (opens in a new tab)
- https://portswigger.net/burp/pro/features (opens in a new tab)
- https://portswigger.net/burp/pro (opens in a new tab)
- https://www.invicti.com/ (opens in a new tab)
- https://www.acunetix.com/ (opens in a new tab)
- https://www.invicti.com/platform-overview (opens in a new tab)
Launch list
Put SelfSec in your release process
Join the launch list to hear when public downloads open, with deployment guidance and the first production-ready release. Nothing is charged during pre-release.