SelfSec DAST · Technical capabilities

From crawl to confirmed finding.

Follow the complete testing path: authenticated crawl past two-factor walls, Android app capture, recon, active attack, adaptive evasion, out-of-band proof, browser-verified confirmation and reports that order the queue for you.

Join the launch list See pricing

Pre-release
Windows and Linux
Local findings database

Product evidenceProduct overview →

21Vulnerability modules

19Database engines fingerprinted

71WAF and bot vendors

LocalCore scan processing

CrawlAuthAttackConfirmOOB · OASTWAF evasionMobileHelperAIReportingSelf-host

The testing path

Not a checklist — a continuous loop

Each stage produces evidence for the next, keeping the workflow understandable from first contact to final action.

Discover

The browser-driven crawler renders the target, maintains authenticated state and adds newly observed routes to a shared queue.

Attack

Classical modules and adaptive evasion test the live surface while the crawl continues instead of waiting for a separate phase.

Confirm

Timing differentials, browser proof and out-of-band callbacks promote a finding from Possible to Confirmed — or refute it outright.

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.

Baseline

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.

SelfSec

SelfSec — Agentic DAST

Crawl and attack share a queue, adaptive follow-up targets the observed surface, and a finding carries the stage it earned — Possible until independent evidence promotes it, Exploited only when impact was actually demonstrated.

Vulnerability modules

SQL InjectionXSSRCECommand InjectionSSRFXXESSTIInsecure DeserializationPath TraversalNoSQL InjectionLDAP InjectionGraphQLCRLF InjectionHost Header InjectionCORS MisconfigurationOpen RedirectAccess Control BypassJWT AttackRequest SmugglingPrototype PollutionWeb Cache Deception

Database engines fingerprinted

MySQL/MariaDBPostgreSQLMSSQLOracleSQLiteDB2SnowflakeClickHouseFirebirdSAP HANARedshiftDuckDBSparkSybaseInformixSAP MaxDBMicrosoft AccessH2HSQLDB

Passive analysis modules

Security HeadersCSRFJWT AnalysisInfo DisclosureTechnology FingerprintJS Library FingerprintSSL/TLSFile UploadPassword AutocompleteContent-Type Mismatch

Recon and discovery

Modern application surfaces

WordPressDrupalJoomlaMagentoSitefinityTelerikKendo UISPA, Blazor & Web ComponentsOpenAPIWSDLGraphQL introspectiontRPCPostmanHARSpring ActuatorWayback seedingCVE matchingOrigin-IP recoveryAndroid APKsmanifest deeplinksWebView surfacesmobile API traffic

Crawl Auth Attack Confirm OOB · OAST WAF evasion Mobile HelperAI Reporting Self-host

Crawl

A crawler that renders like a human, not a bot

4 capabilities in this category

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.

Representative output

Blazor circuitsReact Server Componentsimport mapsHTMXIndexedDBpostMessageCAPTCHA hand-off

bot wall hit → live browser streamed to you → scan resumes

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.

Representative output

OpenAPIWSDL / SOAPGraphQL introspectiontRPCPostmanHARsource maps

schema read, not guessed — typed parameters become typed injection points

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.

Representative output

WordPressDrupalJoomlaMagentoSitefinityTelerikKendo UI

WordPress 6.4 · 3 plugins → 2 CVEs matched · origin IP recovered behind the CDN

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.

Representative output

JSONSocket.IOGraphQL-WSSTOMPSignalRraw

CSWSH probe — is Origin actually enforced?

Auth

Two-factor logins are a configuration, not a blocker

2 capabilities in this category

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.

Representative output

TOTP 2FAMulti-step loginOIDC refresh flowBearerCookieHTTP BasicWebSocket auth frame

TOTP secret in, one-time code derived per login — no manual step

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.

Representative output

Periodic session re-checkAutomatic re-loginLogout avoidanceCSRF token jar

session lapses → re-authenticated mid-crawl, not silently degraded

Attack

An attack engine that thinks, not a checklist

3 capabilities in this category

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.

Representative output

errorboolean-blindtime-basedunionstackedsecond-orderout-of-band

fingerprint → technique → extract · 4 blind-exfiltration strategies

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.

Representative output

CL.TE / TE.CL / CL.0Web cache deceptionCache poisoningPrototype pollutionJWT alg confusionJWK injection

cache attacks require a real cache-hit indicator on the second request

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.

Representative output

403 baseline404 negative controlPath mutationHeader rewritingVerb switching

must diverge from both controls — and not be a WAF page wearing a 200

Confirm

The stage a finding earns, not the one it claims

3 capabilities in this category

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.

Representative output

Chromium re-executionDialog handlerReflection is not execution

no alert() → not Confirmed, however good the reflection looked

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.

Representative output

Independent re-testCross-technique sweepSupersede duplicatesManual re-verify

four confirmation workers · weaker findings superseded, not stacked

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.

Representative output

noisy-OR confidencemedian+stddev baselineadaptive workers14-day anomaly memory

confidence = 1 − ∏(1 − pᵢ), capped at 0.99 — no false certainty

OOB · OAST

Out-of-band proof that never has to leave your network

2 capabilities in this category

The collector is yours, and it can be entirely local

Out-of-band testing normally means routing your findings through a vendor's callback domain. Here there are three choices and you pick. Run your own interactsh server and the scanner generates the DNS records for it and self-tests the channel end to end before a scan depends on it. Or use the collector built into the scanner itself: for private and loopback targets it is selected automatically, listens on the scanner host, and the interaction never leaves your network at all. The managed SelfSec collaborator is the third option, not the default — and even there each session generates its own RSA-2048 keypair on your machine, so what we relay back is ciphertext we cannot read.

Representative output

Your own interactshBuilt-in local collectorAuto-selected for private targetsRSA-2048 per session

RFC1918 or loopback target → local collector → nothing leaves the network

The bugs a response body will never show you

When a payload triggers an interaction from the target's own infrastructure — a DNS lookup, an HTTP callback — SelfSec ties it back to the exact injection point that caused it. That is what promotes blind SQL injection exfiltration, blind SSRF, out-of-band command execution, XXE and deserialization from a guess to a confirmed finding, and it is the only honest way to detect them. The managed collaborator takes no setup at all — it comes with your plan, is authorised by the account the scanner is already signed in to, and there is no token to paste or keep safe. Only that option reports interactions to your account; run a collaborator yourself instead and nothing about the interaction leaves your network.

Representative output

blind SQLiblind SSRFOS commandXXEDeserializationDNS + HTTP callbacks

interaction callbacks confirm what reflection can't · managed channel needs no credential of its own

WAF evasion

A firewall is an obstacle, not a verdict

4 capabilities in this category

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.

Representative output

HTTP/2 desynccharset differentialsize paddingalias overloadparam fragmentationhomoglyph

209 signatures → 71 vendors → chain composed per target

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.

Representative output

30-day evasion memorysuccess-ranked chainper-host learningreordered pre-scan

the chain reorders itself before the first probe of the next 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.

Representative output

baseline-awarebehavioral detectioncustom deploymentsauto-escalation

no signature required — detected by how it blocks

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.

Representative output

Certificate TransparencyDNS recordsCDN range filteringorigin scan

CT logs + DNS → origin IP → scan behind the filter

Mobile

Android apps feed the same engine, not a second product

4 capabilities in this category

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.

Representative output

APK or installed packageloopback capture proxyscope hosts21 vulnerability modules

app request → capture proxy → the same attack workers as HTTP

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.

Representative output

manifest analysisWebViewTLS trustcryptostoragehardcoded secretsdeeplinks

manifest deeplinks → fired at the running app → new captured traffic

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.

Representative output

virtual device bootwireless ADBAppium crawlactivity fallbacksplit APKs

proxy journaled before it changes · restored on teardown, reconciled on restart

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.

Representative output

SSL unpinningBoringSSL / FlutterAPK repackagere-signeddeclared degradation

no root and no repackage → cleartext-only coverage, stated in the run

HelperAI

AI that plans the attack, the engine that confirms it

1 capability in this category

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.

Representative output

OpenAIAnthropicOllama (offline)budget cap $1/runtoken-bucket limiter

AI proposal → classical engine → confirmed · provenance per finding

Reporting

Triage and reporting that ships

3 capabilities in this category

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.

Representative output

CVSS 4.0 vectorCISA KEVFIRST EPSSSSVC decision51 CWEs mapped

KEV-listed · EPSS 0.87 · SSVC: act — ahead of an unexploited high

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 modal. 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.

Representative output

token-level difffalse-positive markingrequest workbenchglobal findingsasset inventory

edit the request, resend it, read the response — without leaving the scan

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.

Representative output

HTMLJSONMarkdownSARIF 2.1.0ATT&CK Navigatorlocal HTTP API

SARIF 2.1.0 → GitHub code scanning, from a local API you can script

Self-host

Core scan processing stays on your machine

1 capability in this category

Local processing with explicit data boundaries

Crawling, payload execution, responses and the findings database remain on the machine running SelfSec. Activation sends product and machine metadata; device diagnostics and out-of-band interaction reporting are separate features with separate controls, and each stays off until you switch it on. AI-assisted analysis can remain on your host through a locally configured runtime, and out-of-band confirmation can stay inside your network entirely.

Representative output

Runs on 127.0.0.1Local findings databaseOpt-in telemetryOffline AI option

core scan processing and findings remain on your host

Where SelfSec pulls ahead

Capability by capability against the tools SelfSec benchmarks against, with sources and verification dates kept alongside every claim.

A workflow comparison based on each vendor's published product information.
Capability	SelfSec DAST	Burp Suite Professional	Invicti
Best fit	Automated local DAST for solo and small teamsSource	Hands-on pentesters and security researchersPortSwigger comparison (opens in a new tab)	AppSec programs managing many applicationsInvicti product page (opens in a new tab)
Testing approach	Automated crawl, attack and classical validationSource	Integrated manual tools and automated scannerPortSwigger features (opens in a new tab)	Automated DAST with runtime validationInvicti pricing (opens in a new tab)
Extensibility and AI	Bring your own model key or use an offline modelSource	BApps, custom checks and Burp AIPortSwigger product page (opens in a new tab)	AI-guided testing and fixesInvicti product page (opens in a new tab)
Out-of-band testing	Collector can be the listener built into the scanner, a server you host, or oursSource	Out-of-the-box tools for out-of-band testingPortSwigger features (opens in a new tab)	Not described on the product pageInvicti product page (opens in a new tab)
Risk prioritization	CVSS 4.0 vector, CISA KEV, EPSS probability and an SSVC decision per CVE findingSource	Not described on the features pagePortSwigger features (opens in a new tab)	Risk scores adjusted from your threat-intelligence dataInvicti product page (opens in a new tab)
Team and CI workflow	SARIF 2.1.0, JSON, HTML, Markdown and ATT&CK Navigator exportSource	Professional focuses on individual testing; DAST serves CI scalePortSwigger comparison (opens in a new tab)	CI/CD automation and enterprise integrationsInvicti pricing (opens in a new tab)
Data boundary	Local core, with activation and optional remote flowsSource	Desktop project and testing workflowPortSwigger features (opens in a new tab)	Cloud and on-premises deployment optionsInvicti pricing (opens in a new tab)

Best fit

SelfSec DAST: Automated local DAST for solo and small teamsSource
Burp Suite Professional: Hands-on pentesters and security researchersPortSwigger comparison (opens in a new tab)
Invicti: AppSec programs managing many applicationsInvicti product page (opens in a new tab)

Testing approach

SelfSec DAST: Automated crawl, attack and classical validationSource
Burp Suite Professional: Integrated manual tools and automated scannerPortSwigger features (opens in a new tab)
Invicti: Automated DAST with runtime validationInvicti pricing (opens in a new tab)

Extensibility and AI

SelfSec DAST: Bring your own model key or use an offline modelSource
Burp Suite Professional: BApps, custom checks and Burp AIPortSwigger product page (opens in a new tab)
Invicti: AI-guided testing and fixesInvicti product page (opens in a new tab)

Out-of-band testing

SelfSec DAST: Collector can be the listener built into the scanner, a server you host, or oursSource
Burp Suite Professional: Out-of-the-box tools for out-of-band testingPortSwigger features (opens in a new tab)
Invicti: Not described on the product pageInvicti product page (opens in a new tab)

Risk prioritization

SelfSec DAST: CVSS 4.0 vector, CISA KEV, EPSS probability and an SSVC decision per CVE findingSource
Burp Suite Professional: Not described on the features pagePortSwigger features (opens in a new tab)
Invicti: Risk scores adjusted from your threat-intelligence dataInvicti product page (opens in a new tab)

Team and CI workflow

SelfSec DAST: SARIF 2.1.0, JSON, HTML, Markdown and ATT&CK Navigator exportSource
Burp Suite Professional: Professional focuses on individual testing; DAST serves CI scalePortSwigger comparison (opens in a new tab)
Invicti: CI/CD automation and enterprise integrationsInvicti pricing (opens in a new tab)

Data boundary

SelfSec DAST: Local core, with activation and optional remote flowsSource
Burp Suite Professional: Desktop project and testing workflowPortSwigger features (opens in a new tab)
Invicti: Cloud and on-premises deployment optionsInvicti pricing (opens in a new tab)

Published capabilities describe different product categories and are not evidence that one scanner finds more vulnerabilities than another. Verified July 25, 2026.

Put SelfSec DAST in your security loop

Join the launch list for product availability and deployment guidance.

Join the launch list See pricing Check availability