-
Notifications
You must be signed in to change notification settings - Fork 2
Detect
The Detect tab is a passive scanner. It never sends a request of its own — it re-reads traffic the proxy already captured and reports what it finds. Browsing a target normally is enough to populate it.
Detect is available in proxy mode only.
The Findings sub-tab lists everything the scanner has surfaced, one row per distinct issue.
Filter with the severity and category multi-selects, a host substring, a rule name or ID, and a free-text search across evidence, URL, rule name, and detail. A second row holds the detection on/off pill, Show false positives, From disabled rules, a Live/Paused toggle for streaming new findings as they arrive, Rescan, and Clear.
The count bar above the table shows how many findings are visible out of the total, with a clickable chip per severity band. Clicking a chip toggles that band's visibility rather than isolating it, so you can peel off the noise a band at a time. Info findings are hidden by default, though the rules that produce them still run — flip the info chip on to see them. Most of the built-in catalog is Info, including every WAF fingerprint, so that chip is the difference between a triage list and a survey of the target's surface.
The table sorts on severity, rule, category, host, URL, occurrence count, and last-seen time. Right-click a row to mark or unmark a false positive, override its severity, delete it, copy the evidence or URL, send the request to Manipulate or Fuzz, copy it as a curl command, stage it for Dead-Drop, or disable the rule that produced it.
Selecting a finding opens the detail pane: rule ID, description, remediation, confidence, target, host, URL, occurrence count, and first and last seen. Below that sits the evidence block, a list of every sighting, and a free-text notes field saved when you click away. Three viewers — Response, Request, and Rendered — show the message the finding came from with the evidence range highlighted.
Evidence for rules that handle secrets is masked in the table and detail pane. Click the eye icon to reveal the raw value. Redaction here guards against shoulder-surfing and screen sharing, not storage — see Storage below.
A finding's identity is derived from the rule, the host, and the rule's grouping dimension — not from a request ID or a timestamp. Rescanning reproduces the same identities, so it is idempotent: findings you have already triaged are updated in place rather than duplicated.
This means false-positive marks, severity overrides, and notes survive a rescan. Working through a large result set over several sessions is safe; nothing you have already dispositioned comes back.
Rescan re-reads everything currently in History. Because Detect only ever sees captured traffic, a rescan after enabling a rule or writing a new one will find matches in traffic you collected earlier.
The Rules sub-tab is the live catalog of every check, grouped by category and collapsible. Filter by category, severity, and search, and narrow to built-in or custom rules, or to enabled or disabled ones.
Toggle a rule with its checkbox, or use Enable all / Disable all on a category header. Clicking a rule's hit count jumps to the findings table filtered to that rule.
Open a rule to see its full definition — pattern, target, grouping, content-type and status gates, post-filters, and remediation text. Built-in rules are read-only, but you can change two things on them: whether they are enabled, and their severity. A severity override applies to findings from the next scan onward. Reset to defaults undoes both.
The catalog carries a large family of WAF signatures: 162 rules covering 88 web application firewalls, ported from nuclei's Global WAF Detect Matchers with attribution under third_party/nuclei/. That is roughly half the built-in catalog by count.
The engine matches one message part per rule, so a vendor that fingerprints in both the body and the headers is two rules. Every vendor has a response-body rule, waf-<vendor>, which catches block-page text; 74 of them also have waf-<vendor>-hdr, named "… (headers)", over response headers, which catches Server and Set-Cookie fingerprints on ordinary 200s where no block page ever appears.
All of them are Info severity, Low confidence, in the Disclosure category, and grouped by host — a WAF is one finding per host however many pages carry its signature. That combination is deliberate: knowing what sits in front of a target shapes how you approach it, but it is not a weakness in the target, and a fingerprint per URL would bury everything else.
If they are noise on a given engagement, Disable all on the Disclosure category header switches them off — along with the rest of that category, so narrow with the search box first if you want to keep the other Disclosure rules.
- Secrets — API keys, tokens, and private key material for cloud providers, SaaS platforms, and payment processors.
- Credentials — usernames and passwords in transit or at rest: credentials in URLs and query strings, database connection strings, and exposed credential files.
- PII — personal data such as email addresses, national identifiers, payment card numbers, and phone numbers.
- Access — administrative and management surfaces reachable on the target: admin panels, authentication challenges, introspection endpoints, and product-specific consoles.
- Disclosure — information the application leaks about itself: stack traces, debug pages, database errors, version fingerprints, internal hostnames and paths, files that should not be served, and the WAF fingerprints described above.
- Headers — security header problems, including missing, weak, or contradictory transport, framing, content-type, and CORS policy.
- Cookies — cookie attribute problems such as missing flags, scope that is too broad, and mismatches between a cookie and the transport carrying it.
Most rules are regular expressions. Some are analyzers — Go functions that make relational or absence checks a regex cannot express, such as noticing that a security header is missing entirely, that a login form posts over plain HTTP, or that a cookie's flags contradict the connection it arrived on. Analyzers behave like any other rule: you can disable them and override their severity, but you cannot edit or clone them.
Severity answers "how bad is this if it is real":
- Info — not exploitable on its own. Discloses a surface or an identity: an exposed panel, a missing header, a version fingerprint.
- Low — a real but minor weakness, or disclosure that goes beyond an identity: a config file, a verbose error, a directory listing, a filesystem path, a CORS or redirect misconfiguration.
- Medium — the catch-all for everything between low and high.
- High — account credentials, sensitive API keys, database connection strings, and lower-sensitivity personal data.
- Critical — high-grade personal data such as a national identifier or payment card, or something that constitutes severe compromise on its own: remote code execution, an authentication bypass, a served database dump.
Every credential is High and never Critical. A credential is a step toward compromise, not compromise itself, and treating them as Critical drowns the band that should be reserved for findings that end the engagement.
Confidence is a separate axis. It describes how likely the match is to be a true positive, independent of how bad it would be. A high-severity, low-confidence finding is worth a look; a low-severity, high-confidence one usually is not urgent. Both are overridable.
Click + New rule, or open a built-in and choose Clone to custom to start from an existing definition.
Custom rules are regular-expression rules. Patterns are Go RE2, which means no lookahead, no lookbehind, and no backreferences — RE2 trades those for a guarantee that a pattern cannot blow up on hostile input. The editor validates your pattern and reports the compile error verbatim if it fails.
The rule form covers name, description, category, severity, confidence, target (response body, response header, request body, request header, or URL), grouping, capture group, a minimum entropy threshold, and whether to redact the matched value in stored evidence. Grouping decides what counts as a distinct finding: by evidence for secrets and personal data, by URL for panels and exposed files, or by host for header and cookie issues.
A Test sample box takes a block of text and shows every match the pattern produces, labelled with its offset and whether it survived the rule's post-filters. Use it before enabling a rule against live traffic.
Minimum entropy is a validator, not a detector. It runs after a placeholder check that rejects obvious template and sample values, so a rule matching api_key = "your_api_key_here" is discarded without you having to write the exclusion yourself.
Deleting a custom rule removes the rule. Findings it already produced are kept.
Open Settings from the Rules toolbar. These apply to the engine as a whole and are saved with the project:
- Scan in-scope traffic only — on by default. Respects the scope rules from Settings.
- Scan requests as well as responses — on by default.
- Save findings in the project file — on by default.
- Clear findings when history is cleared — off by default, so clearing History leaves your findings intact.
- Max body bytes — how much of a response body to scan. Defaults to 1 MiB.
- Exclude hosts — a comma-separated list of hosts to skip entirely.
Some captured messages cannot be scanned, and Detect reports this rather than quietly counting them as clean. An amber unreadable badge in the count bar shows how many were skipped.
Bodies compressed with brotli or zstd cannot be decoded, and binary bodies are skipped. Content types and file extensions on the skip list — images, fonts, media, archives — are also passed over. Note that .js and .css are deliberately not skipped, because both routinely carry keys and internal paths.
Findings are saved into the project file when Save findings in the project file is on, and are restored when you load that project. The saved set is capped, keeping the highest-severity and most recent findings, but anything you have triaged is always kept regardless of the cap.
The unmasked value behind a redacted finding is stored in the project file. Redaction is a shoulder-surfing and screen-sharing control, not encryption at rest — treat a project file containing findings as sensitive material and handle it accordingly.
Custom rules travel with a project configuration published to a team server; findings do not, because triage is per-operator and evidence can contain live credentials. See Team-Server and Projects.