Redaction Coverage

This reference explains current sanitizer coverage, likely blind spots, and how to contribute improvements safely. It is intended for support leads, security reviewers, and engineers who need predictable masking behavior during incident handoff.

All examples on this page use fake-only strings.

What we redact

Coverage behavior notes

• The sanitizer favors precise, context-aware masking over broad destructive replacement.
• Output is designed to preserve debug structure (method, path, status, ids, timestamps).
• Report output summarizes what categories were masked and how many replacements occurred.
• Manual review warnings are shown for suspicious leftovers.

What we might miss (manual review required)

No regex-based system can guarantee perfect coverage. Always manually review output for:

• custom internal header names not yet in defaults
• unusual token formats that do not match known patterns
• nested or encoded payload segments with secret values
• domain-specific identifiers that are sensitive in your environment
• binary blobs or compressed content that hides values

For these cases, a human review pass is mandatory.

High-confidence manual review checklist

• Scan for password, secret, token, key, session, auth labels with unmasked values.
• Look for long high-entropy strings that remain visible.
• Check URL query strings for leftover auth/session params.
• Confirm no private key blocks remain.
• Confirm no DB credentials remain in connection strings.

If you find any gap, report it through the community loop.

Validate behavior in browser

Use Redaction Test Lab to run public cases against current logic:

• run full suite or filtered categories
• inspect PASS/FAIL results
• view sanitized output and report side by side

This makes coverage claims testable and transparent.

How to contribute coverage improvements

• Open Contribute hub
• Submit a redaction gap issue with fake-only examples
• Optionally propose a matching Rule Pack update

Direct issue form:

• https://github.com/marginofsafety-hi/ticket-safe-sanitizer/issues/new?template=redaction-gap.yml

High-quality submissions should include:

• observed pattern and context (curl, log, har)
• expected replacement marker
• impact severity
• notes on false-positive risk

Security note

Never paste real secrets into tools, docs, issues, or pull requests. Use FAKE_EXAMPLE_* placeholders only.

Related resources

• What we redact
• Contributing guide
• Rule Packs
• How to share logs safely

Coverage quality improves through iteration. Public docs + public tests + community submissions create a stronger trust surface than static claims.