Skip to main content

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.

Idempotence means that applying the same operation twice produces the same result as applying it once. For Evidence Sanitizer, this means you can run sanitize on a file that has already been sanitized and the output will be byte-for-byte identical to the input — no double-wrapping, no changed counts, no altered markers. This property holds regardless of which rule families were triggered in the original run.

​
How the Marker Policy Works

Each rule family maintains an approved set of markers. Before emitting a finding, the sanitizer checks whether the current credential section or value field equals an approved marker exactly:
  • Authorization headers — approved markers are <REDACTED:authorization.bearer>, <REDACTED:authorization.basic>, and <REDACTED:authorization.credentials>. If the complete credential section (after the scheme and whitespace) equals any of these exactly, no finding is produced.
  • Proxy-Authorization headers — approved markers are <REDACTED:proxy_authorization.bearer>, <REDACTED:proxy_authorization.basic>, and <REDACTED:proxy_authorization.credentials>. Same skip logic applies.
  • Cookie headers — approved markers are <REDACTED:cookie.value> and <REDACTED:cookie.header>. An individual cookie value that equals <REDACTED:cookie.value> exactly is skipped; a full trimmed header value that equals either marker exactly is skipped.
  • Sensitive headers — the single approved marker is <REDACTED:header.secret>. A trimmed header value equal to it exactly produces no finding.
  • Query parameters — the single approved marker is <REDACTED:query.secret>. A raw parameter value equal to it exactly produces no finding.
  • JSON string values — the single approved marker is <REDACTED:json.value>. A raw JSON string payload equal to it exactly produces no finding.
  • Form fields — the single approved marker is <REDACTED:form.value>. A raw form field value equal to it exactly produces no finding.
When no findings are produced, apply_findings makes no replacements and the output text is identical to the input text.

​
Concrete Example

Suppose your evidence file contains: 
POST /api/token HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.secret
X-API-Key: sk-live-abc123
Cookie: session=abc; theme=dark

{"access_token":"tok_xyz","token_type":"Bearer"}
After the first run: 
evidence-sanitizer sanitize evidence.txt --output evidence.sanitized.txt
evidence.sanitized.txt contains: 
POST /api/token HTTP/1.1
Authorization: Bearer <REDACTED:authorization.bearer>
X-API-Key: <REDACTED:header.secret>
Cookie: session=<REDACTED:cookie.value>; theme=dark

{"access_token":"<REDACTED:json.value>","token_type":"Bearer"}
After the second run: 
evidence-sanitizer sanitize evidence.sanitized.txt --output evidence.sanitized2.txt
evidence.sanitized2.txt is byte-for-byte identical to evidence.sanitized.txt. The second run reports zero rules triggered because every marker is recognized as an approved value for its rule family.
You can safely re-run sanitize on output files without any risk of double-redaction, nested markers, or inflated rule counts. This makes it safe to include already-sanitized files in pipelines or share them with colleagues who may also run the tool on the same file.

​
Why This Matters in Practice

Evidence files in real workflows are sometimes processed more than once — for example, when a team member sanitizes a capture and then a reviewer runs the tool again before pasting into a report. Idempotence ensures this is always safe:
  • Partially sanitized files are safe to re-sanitize. If only some rules triggered on a first pass (for example, a file was sanitized before the query-parameter rule existed), a second run applies the newer rules without altering already-replaced markers.
  • Files from different sources may already contain markers. If a colleague has already sanitized a snippet before sharing it, running the tool again produces no changes and no extra counts.
  • Counts remain accurate. Because approved markers are skipped, the rule counts reported by each run reflect only the replacements actually made in that run — not the total number of markers in the file.

​
Edge Case: Wrong-Family Markers

The idempotence skip is deliberately per rule family, not global. A marker from one family that appears inside a header belonging to a different family is treated as a raw credential value and re-redacted. For example, if <REDACTED:authorization.bearer> appears as the credential section of a Proxy-Authorization header, the proxy finder does not recognize it as an approved proxy marker. It treats it as a raw string and replaces it with <REDACTED:proxy_authorization.bearer>: 
# Input (after a previous partial sanitization pass)
Proxy-Authorization: Bearer <REDACTED:authorization.bearer>

# Output (correct proxy marker applied)
Proxy-Authorization: Bearer <REDACTED:proxy_authorization.bearer>
This is intentional. The goal is to ensure that proxy rule counts and authorization rule counts in reports always accurately reflect the kind of credential present, not to propagate a misclassified marker silently.

​
Edge Case: Markers Embedded in Larger Values

The idempotence skip fires only when the entire relevant section equals the approved marker. If an approved marker is embedded as a substring of a longer raw value, the whole section is still treated as raw and redacted: 
# Not idempotent — the credential section is longer than the marker
Authorization: Bearer <REDACTED:authorization.bearer>.suffix

# Output — the entire credential section is replaced
Authorization: Bearer <REDACTED:authorization.bearer>
This behavior prevents scenarios where a raw value that happens to contain a marker string would be left partially unsanitized.

Build docs developers (and LLMs) love

Get started for freeTalk to us