Evidence Sanitizer is a local-first command-line tool for creating sanitized copies of authorized penetration-testing evidence. When testers and security engineers need to share raw HTTP traffic, API logs, or captured request/response pairs — in reports, tickets, Jira comments, or shared notes — those artifacts routinely contain live credentials, session tokens, and API keys. Evidence Sanitizer processes one text file at a time, replaces known sensitive values with deterministic redaction markers, and prints a safe report showing only which rule families fired and how many times. No raw values, no excerpts, no guesswork.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/facunemi/evidence-sanitizer/llms.txt
Use this file to discover all available pages before exploring further.
Who It’s For
Evidence Sanitizer is built for three overlapping groups:- Penetration testers who need to paste HTTP evidence into reports or findings without accidentally leaking Authorization headers, session cookies, or API keys.
- Security consultants preparing deliverables for clients where raw credentials must never appear in report attachments or collaboration tools.
- Internal security engineers triaging findings and sharing evidence across teams, tickets, or code review threads where inadvertent secret exposure is a real risk.
Core Design Principles
Evidence Sanitizer is built on four explicit design principles that define both what it does and what it intentionally does not do: Local-first. All processing happens entirely on-device. There is no network access, no telemetry, no external API calls, no plugin system, and no persistence layer. Your evidence files never leave the machine running the tool. Deterministic. Redaction markers are fixed strings derived from rule IDs (<REDACTED:rule.id>). Given the same input, the tool always produces the same output. Markers are also idempotent — running the sanitizer on already-sanitized output does not double-redact or corrupt existing markers.
Best-effort. Evidence Sanitizer covers common HTTP-style evidence patterns thoroughly but does not claim complete coverage of every possible secret format. Unsupported formats — multipart bodies, XML, HTML, JavaScript, chunked transfer encoding — may retain secrets. The tool operates within its documented rules and is explicit about its boundaries.
Non-destructive. The source input file is never modified in place. Output is always written to a separate, explicitly provided path. Existing output files are never overwritten. A --dry-run mode performs detection and reporting without writing any output at all.
What It Sanitizes
Evidence Sanitizer applies 12 named rules covering the most common credential patterns found in HTTP-style pentest evidence. Each rule has a fixed ID and a deterministic replacement marker:| Rule ID | Marker | Applies to |
|---|---|---|
authorization.bearer | <REDACTED:authorization.bearer> | Authorization: Bearer credentials |
authorization.basic | <REDACTED:authorization.basic> | Authorization: Basic credentials |
authorization.other | <REDACTED:authorization.credentials> | Other syntactically valid Authorization schemes |
proxy_authorization.bearer | <REDACTED:proxy_authorization.bearer> | Proxy-Authorization: Bearer credentials |
proxy_authorization.basic | <REDACTED:proxy_authorization.basic> | Proxy-Authorization: Basic credentials |
proxy_authorization.other | <REDACTED:proxy_authorization.credentials> | Other syntactically valid Proxy-Authorization schemes |
cookie.value | <REDACTED:cookie.value> | Individual Cookie values in safely parsed headers |
cookie.header | <REDACTED:cookie.header> | Whole Cookie header fallback when safe parsing fails |
header.secret | <REDACTED:header.secret> | Selected sensitive API/auth header values (e.g. X-API-Key, X-Auth-Token) |
query.secret | <REDACTED:query.secret> | Selected sensitive URL query parameter values |
json.value | <REDACTED:json.value> | String values of approved sensitive JSON field names |
form.value | <REDACTED:form.value> | Raw values of approved sensitive form-urlencoded field names |
What It Does Not Do
Evidence Sanitizer is deliberately scoped. It is not a general-purpose DLP system. The following are explicitly out of scope:- No batch processing. The tool processes exactly one file per invocation. Directory scanning is not supported.
- No configuration files. There are no rule config files, allowlists, denylist overrides, or user-defined patterns. Rules are fixed and versioned with the tool.
- No network activity. No telemetry, no license checks, no update pings, no external lookups of any kind.
- No entropy-based detection. The tool uses deterministic named-rule matching only. It does not scan for high-entropy strings or use heuristics beyond its documented rule set.
- No XML, HTML, or JavaScript parsing. Evidence containing secrets embedded in these formats may not be fully redacted.
- No multipart bodies. Multipart form data is not parsed or scanned.
- No full HTTP parsing. The tool is line-oriented. Folded headers, chunked transfer encoding, and Content-Length-based body parsing are not supported.
- No
Set-Cookiesanitization. Only the request-sideCookieheader is in scope. - No recursive URL parsing or percent-decoding. Query parameters are matched as raw strings; percent-encoded names are not decoded before matching.
Evidence Sanitizer is best-effort within its documented rules. Unsupported formats and patterns may retain secrets. Always review sanitized output manually before sharing it. Do not use Evidence Sanitizer as a substitute for manual review or organizational data handling requirements.
Get Started
Quickstart
Install Evidence Sanitizer, sanitize your first evidence file, and understand the report output in under five minutes.
CLI Reference
Full reference for the
sanitize command, all flags, exit codes, and report format.