Ticket-Safe Sanitizer

Docs

How to Share Logs Safely

A practical workflow to share logs, JSON, and traces without leaking credentials or personal data.

Written by Security Architecture Team • Reviewed by Lead Engineer

Updated: 2026-02-24

How to share logs safely

Sharing logs quickly is often the difference between a 20 minute fix and a multi-hour escalation loop. The problem is that raw logs usually contain credentials, session data, customer identifiers, and internal endpoint details that should not leave your security boundary. A rushed copy-paste into a support thread can create a second incident while you are still handling the first one.

Advertisement

This guide gives a repeatable process you can use before posting in email, Jira, GitHub, or vendor portals. The goal is to keep the technical value of the log while removing the parts that can be abused.

Why it matters

Logs carry more secret material than most teams expect. Authorization headers, JWTs, API keys, cookies, and database URLs are often recorded together with stack traces and request payloads. Even a single leaked token can allow replay, data access, or privilege escalation depending on the scope of the credential.

Safe sharing also improves engineering quality. When teams standardize on sanitized snippets, reviewers can focus on behavior and evidence instead of asking security follow-up questions. That means faster incident triage, faster vendor support responses, and fewer back-and-forth messages asking someone to "remove secrets and resend."

Step-by-step checklist

  • Start from the smallest useful slice of logs. Export only the timeframe and request IDs needed to reproduce the issue.
  • Remove full dumps when a short timeline is enough. Large files increase leak surface and make review harder.
  • Run the text through Log Sanitizer first. If you are sharing network traces, run HAR Sanitizer.
  • Confirm these fields are masked: Authorization, x-api-key, cookies, token-like query params, and JSON keys like client_secret.
  • Check for service-specific secrets: AWS keys, GitHub tokens, Slack tokens, Stripe keys, SendGrid keys, and private key blocks.
  • Keep structure, not raw values. Preserve method, path, status code, and field names; replace only sensitive values.
  • Add minimal context with each snippet: environment, timestamp (UTC), request ID, and expected vs actual behavior.
  • Add ownership and next step in the same message so escalation does not stall.
  • Re-scan the final paste before sharing externally.
  • If uncertain, prefer one more masking pass before posting.

Safe snippet examples

Before:

{
  "timestamp": "2026-02-24T17:18:11Z",
  "request_id": "req_9f2",
  "Authorization": "Bearer eyJhbGciOi...",
  "x-api-key": "sk_live_1234567890",
  "db": "postgres://app_user:super_secret@db.internal/prod",
  "email": "user@example.com"
}

After:

{
  "timestamp": "2026-02-24T17:18:11Z",
  "request_id": "req_9f2",
  "Authorization": "[REDACTED:AUTH]",
  "x-api-key": "[REDACTED:API_KEY]",
  "db": "postgres://app_user:[REDACTED:DB_PASS]@db.internal/prod",
  "email": "[REDACTED:EMAIL]"
}

Before:

curl -H "Authorization: Bearer eyJ..." -H "Cookie: sessionid=abc" "https://api.example.com/v1/orders?token=qwerty"

After:

curl -H "Authorization: [REDACTED:AUTH]" -H "Cookie: [REDACTED:COOKIE]" "https://api.example.com/v1/orders?token=[REDACTED:QP]"

A practical sharing format

Use this message template when escalating:

  • Incident summary: one sentence with impact.
  • Sanitized evidence: 1 to 3 snippets, each under 50 lines.
  • Reproduction steps: command or request sequence.
  • Scope: affected environment, endpoints, and start time.
  • Owner and next checkpoint time.

This keeps threads actionable without exposing secrets.

Related reading