Finding Validators
0 separates a vulnerability hypothesis from runtime evidence. Category-specific validators execute probes and evaluate observations with ordinary code. These are distinct from model-based reachability analysis and independent review. A model’s agreement or confidence score does not establish runtime exploitation.
Current checks
Section titled “Current checks”| Category | What the validator observes | Important limits |
|---|---|---|
| Reflected XSS | Chromium captures an alert with an exact, fresh random token. | Requires Playwright and Chromium. GET and form POST probes preserve the real response’s CSP. Reflection alone stays unverified; stored and DOM XSS are not comprehensively covered. |
| SQL injection | At least two of response-size differences, delayed responses, and database-error patterns. | These signals can be misleading on unstable or generic error pages; they are not a universal proof of SQL execution. |
| SSRF | A local HTTP collector receives the probe’s fresh nonce. | The target must be able to reach the collector. A remote target’s loopback is not the scanner’s loopback. |
| Command/code injection | A local collector receives a nonce after command-shaped probes. | Callback evidence needs review to distinguish command execution from other URL-fetch behavior; this is not a general RCE harness. |
| Path traversal | A traversal response contains a passwd-like signature. | Static text can resemble that signature. A controlled, unpredictable file marker is stronger evidence and is not yet this oracle’s default. |
| ID/resource access | An exact operator-provided fixture is replayed as owner and comparison identities; both successful responses contain the known private owner marker. | Requires distinct credentials and declared restricted ownership. Without a matching fixture, numeric-ID response differences remain unverified candidates. Write authorization needs an owner-side workflow postcondition. |
These checks use the finding’s recorded request and the scan target. The agentic web scan runs category checks during verification. Its save-finding hook can also return inline validator feedback for high and critical findings. The standalone category dispatcher is not automatically run for every static review, chat message, or CLI command.
Interpreting results
Section titled “Interpreting results”A successful XSS execution check is stronger than HTML reflection. Likewise, source analysis, an HTTP 200, changed response text, or a zero command exit code must not automatically become an exploit claim.
Keep hypotheses that have not reproduced for follow-up. An unavailable browser, unreachable collector, missing authentication, or broken fixture means the validator could not establish the result; it does not prove the application is safe. Report consumers should inspect evidence and distinguish candidates from reproduced findings. Current aggregate scan reports can include both.
The category oracle result (verified, confidence, evidence, reason) is
not the standalone replay JSON contract. See Verification Results
for replay status, assertions, retained artifacts, and 0 verify commands.
Run the real browser qualification
Section titled “Run the real browser qualification”From a source checkout with dependencies and Playwright Chromium installed:
ZERO_TEST_BROWSER_ORACLES=1 pnpm --filter @0/core exec vitest run \ src/triage/oracles.browser.test.ts src/triage/oracles.test.tsThe browser suite starts loopback-only fixture endpoints and uses the actual inline validator and Chromium. It confirms vulnerable GET and POST endpoints, rejects escaped, CSP-blocked and JSON reflection and unrelated alerts, and keeps differing public resources unverified. No live third-party target or model provider is needed. Without the environment flag the optional browser suite is skipped; when explicitly requested, a missing browser must fail qualification.
Deployment limits
Section titled “Deployment limits”Run probes only in the approved environment. The category oracle’s direct HTTP transport is not yet a complete scope-enforcement boundary: evidence URLs, redirects, response sizes and total execution budgets need further hardening. Inline, batch, and delegated PoV category checks use the scan executor’s scoped transport. Raw HTTP evidence retains application headers and JSON/form bodies; configured identity credentials replace recorded authentication. Browser probes also route network requests through that transport and retain response CSP. Batch checks start from configured credentials; they do not inherit a previous agent phase’s rotated cookie jar. Curl evidence parsing remains best-effort. Standalone oracle calls without a supplied context still use direct fetch; this qualification does not establish scope enforcement for those callers. Do not infer isolation or target authorization from a validator result.
The separate runtime-verifier stage still has a placeholder provisioning driver; it does not automatically boot an arbitrary repository into a working target. Nor does this qualification establish end-to-end SmolVM or private Azure/AWS deployment. Those require separate environment tests.
Authenticated IDOR fixtures
Section titled “Authenticated IDOR fixtures”Supply restricted, file-backed credentials with scan --identities identities.json.
Use unique labels for an owner Admin, a second tenant Admin, and a Member. An
identity with no auth is an anonymous control. Do not combine --auth and
--identities.
--access-control-fixtures fixtures.json accepts an array of known read-only
ownership contracts. Seed a private synthetic marker in the owner tenant first:
[ { "url": "https://app.example.test/api/artifacts/known-uuid", "ownerIdentity": "tenant-a-admin", "comparisonIdentities": ["tenant-b-admin", "tenant-a-member"], "ownershipMarker": "PRIVATE_SYNTHETIC_OWNER_CANARY_12345" }]Do not use public names or shared fields as markers. Fixtures match the exact
GET URL, including its query string; a fixture cannot authorize a destination.
The IDOR oracle returns request/response evidence with identity labels and
credential redaction. Public pages, successful status codes without a private
marker, stale sessions, identical credentials and unavailable transport cannot
confirm an ownership break. For unauthorized changes, use
access_control_workflow with a disposable resource and an owner-side state
observation before and after the actor’s actions.