Parse Burp Suite Project Files

Burp Project Parser extracts and searches data from Burp Suite Professional project files (.burp) for security auditing. It delegates parsing to Burp Suite Professional itself via the burpsuite-project-file-parser extension - it does not parse .burp files directly - and requires both Burp Suite Pro and the extension JAR installed via Extender > Extensions. Access runs through a wrapper script:

{baseDir}/scripts/burp-search.sh /path/to/project.burp [FLAGS]

configured via BURP_JAVA and BURP_JAR environment variables for platform compatibility. The core discipline is always using sub-component filters instead of full dumps: proxyHistory.request.headers or proxyHistory.response.headers return small (<1KB/record) header-only data, while full proxyHistory, siteMap, or any *.response.body filter can return gigabytes and must be avoided as a default. The recommended workflow starts with headers only (piped through head -c 50000), uses jq to find interesting URLs from those headers, and only then searches bodies with a targeted regex, always truncating each body field to 1000 characters.

It also drives a six-step investigation workflow: identify the scope (vuln type, endpoint, or header pattern being searched for); search Burp's own auditItems findings first, filtering by severity; check confidence scores to separate actionable findings from noise; extract the affected URLs to map the attack surface; search raw proxy traffic for context around a specific pattern; and finally validate manually, since Burp findings are indicators rather than proof.

Use this skill when searching response headers or bodies with regex patterns, extracting security audit findings from Burp projects, dumping proxy history or site map data, or analyzing HTTP traffic captured in a Burp project file.

Do not treat Burp's own severity rating alone as a triage signal: the skill pairs severity (High/Medium/Low) with confidence (Certain/Firm/Tentative) - a High-severity, Certain-confidence finding is likely a real vulnerability worth prioritizing, a High-severity, Tentative-confidence finding is frequently a false positive that needs verification first, and a Medium-severity, Firm-confidence finding is worth investigating but may still need manual validation. Also watch for HTTP body encoding gotchas: response bodies may be gzip-compressed, chunked, or non-UTF8, so a regex that works on plaintext can silently fail on an encoded response - if a search returns fewer results than expected, check for compression, try a broader pattern, or search headers first.

Given a .burp project file, the skill outputs filtered JSON records via regex search operations (searching response headers, searching response bodies with required body truncation) or structured audit-item extraction, always checking result size before retrieving data: a required first step runs wc -cl to check both line/record count and byte size against a table (safe: under 50 lines/50KB; too broad: 200+ lines or 200KB+; stop: 1000+ lines or 1MB+), since a single oversized response can pass a naive line-count check but fail on bytes. If a search is too broad, it's refined via sub-component filters, narrower regex patterns, or jq pre-filtering, and output is always capped with head -c to a 50KB maximum. Proxy history may also be incomplete by design - Burp's scope filters, intercept settings, or browser traffic not routed through the proxy can all leave gaps, so missing expected traffic means checking the original project's scope and proxy settings rather than assuming the capture was exhaustive.

Built on Burp Suite Professional and the burpsuite-project-file-parser extension, with platform-specific configuration for macOS, Windows, and Linux. Five named rationalizations are explicitly rejected: assuming a regex looks correct without verifying on sample data (encoding/escaping cause silent failures), treating high severity as automatically must-fix without checking the confidence score, treating all audit items as relevant regardless of the actual threat model, assuming proxy history is complete when Burp's scope/intercept settings may have filtered it, and treating a Burp finding as a proven vulnerability rather than something requiring manual verification.

Security engineers auditing HTTP traffic captured in Burp Suite project files who need to search large proxy histories or site maps without overflowing context or retrieving gigabytes of response bodies, and who want a structured investigation workflow plus built-in guardrails against the specific false-confidence shortcuts that lead to missed vulnerabilities or false reports.