Search

Search is the global lookup tool. Where the Logger’s search bar filters the visible flow list, the Search view runs broader queries across request, response, headers, params, cookies, body, and matches across all flows in the project (or all projects). It also supports regex, structural patterns, and saved queries.

🔗Quick Start

  1. Open the Search view (sidebar or Ctrl+Shift+F).
  2. Type a query — plain substring works for most cases.
  3. Pick search scope (request / response / both) and search type (substring / regex / glob).
  4. Apply optional filters (method, host, status, time range).
  5. Hit Enter or click Search.

Results stream as they’re computed against the SQLite store with FTS5 indices.

🔗Search Scope

Toggle which parts of each flow are inspected:

🔗Request

  • URL (path + query)
  • Method
  • Headers (key + value)
  • Cookies
  • Body (UTF-8 only — binary bodies are skipped unless Search Binary is on)
  • Params (query, form-urlencoded, JSON-flattened)

🔗Response

  • Status code + reason phrase
  • Headers
  • Set-Cookies
  • Body (UTF-8)

You can enable both — useful for “find every flow that mentions admin anywhere”.

🔗Search Type

Three modes:

  • Text (default, SearchType::Literal) — plain text match
  • Regex — full Rust regex syntax with capture groups
  • Wildcard — * and ? wildcard matching

Case sensitivity is a separate option (off by default). Toggle with the case-sensitive switch in the toolbar.

🔗Data Scope

Pick which data set the query runs against:

  • Flows (default) — captured HTTP flows, the Logger’s data set
  • Findings — scored findings from every source:
    • scanner_findings (active + passive scanner)
    • bac_findings (Pro — BAC active audit output)
    • nerve_findings (JWT / IDOR / auth-header leaks / cloud tokens classified by the Nerve param analyzer)
    • client_side_findings (postMessage misconfig, DOM sinks, origin-guard issues)
  • Repeater — tabs / requests captured through the Repeater view
  • Intruder — Intruder attack results
  • WebSocket — frames from the websocket_messages table

The Findings scope unified in one stream across four historical finding tables — a single “admin” search over the Findings scope covers scanner issues, BAC CrossTenantAccess findings, Nerve-classified IDOR params, and client-side DOM sinks simultaneously.

🔗Filters

Combine with the search query (AND logic):

  • Method — multi-select
  • Host — autocompleted dropdown
  • Status — exact code or range (2xx / 3xx / 4xx / 5xx)
  • Content-Type — substring
  • Min / Max Length — response body size bounds
  • Min / Max Latency — response time bounds
  • Time range — captured between two timestamps
  • Tags — flow must have these tags
  • Project — limit to active project, or search across all
  • In-scope only — toggle

🔗Sort

The SortField enum: Score, Status, Host, Path, Method, Length, Latency, Time. Each can sort ascending or descending via SortOrder. Score sorts by the search engine’s per-result match score (most useful when the query is non-empty).

🔗Result View

Each row shows method, URL, status, body size, latency, and a snippet with the matched span highlighted. Click any row to open the full flow in a side pane (request + response + headers + matched text in context).

🔗Bulk Actions

Same as the Logger: multi-select results, then bulk send to Repeater / Intruder / Scanner / Comparer / Findings, bulk flag, bulk delete, bulk export.

🔗Saved Queries

The bookmark icon on the search bar saves the current query + filter combination. Saved queries appear in the dropdown for one-click recall. Persisted per project.

Useful saved queries to start with:

  • Authorization: Bearer (request scope) — every authenticated flow
  • error|exception|stack trace (regex, response scope) — error responses worth inspecting
  • password|secret|token|api_?key (regex, both scopes) — credential leakage
  • eval\(|innerHTML|document\.write (regex, response scope, content-type contains javascript) — DOM XSS sinks in JS responses

🔗Autocomplete

The search input has live autocomplete:

  • Recent searches (per project)
  • Saved queries
  • Common operators (status:5xx, method:POST, host:api.example.com)
  • Live host suggestions from the active project

🔗HTTPQL Inline Operators

The search bar (and Logger filter bar) parse a structured HTTPQL syntax. Real operators (re-exported from hugin_store::filter_query):

  • method:POST (alias m:)
  • host:*.example.com (alias h:)
  • status:401 / status:4xx / status:>=500 (alias s:, code:)
  • path:/api/v1/users (alias p:, url:)
  • latency:>500 — millisecond comparisons (>, <, =, ranges)
  • size:>10000 — response body size
  • flag:true — flagged flows
  • ct:json / content-type:json
  • has:body / has:cookies / has:auth
  • tag:auth
  • header:Authorization — request or response header presence
  • param:user_id
  • scope:in / scope:out
  • req.body:admin — substring in request body
  • resp.body:error — substring in response body
  • resp.header:Server

Negation operators: !method:GET, !host:cdn.example.com, !status:200, !path:/health.

Combine tokens with spaces (AND): method:POST status:401 header:Authorization — every authenticated POST that returned 401.

🔗Performance

The search engine in hugin_store::search iterates over candidate flows in memory and applies the chosen SearchType (literal / regex / wildcard) against each configured scope (request line, headers, body, response, etc.). For very large projects, narrow with the structural HTTPQL filters above (host:, status:, time range) before running an expensive regex over body content — those operators run as SQL filters and reduce the candidate set before the in-memory search.

The toolbar Limit caps result count; lower it for snappier interactive searching on huge captures.

🔗MCP

The search_flows and intelligence MCP tools cover the same search surface. Use search_flows with the query param for direct substring matching, or flow_analysis and intelligence for the more structured cross-flow analytics.