How to Find Obvious Secrets Before Sharing Logs

Problem

Logs often contain Authorization headers, signed URLs, session IDs, emails, JWTs, Base64 blobs, and API keys. Sharing them unchanged in a ticket or chat can leak access.

Solution

Run a local review pass with Smart Extract, Regex Tester, JWT Decoder, URL Parser, and Base64 Decoder. Redact anything that looks like a credential before sharing.

Workflow

1. 1Extract structured values first
   Use Smart Extract to list URLs, emails, dates, JSON blocks, and other structured spans. These are the places where secrets are most likely to hide.
2. 2Search for common credential labels
   Use Regex Tester or browser search for labels such as authorization, bearer, token, api_key, client_secret, password, cookie, set-cookie, x-api-key, and signature.
3. 3Decode tokens before deciding they are safe
   A JWT payload can contain emails, tenant IDs, account IDs, scopes, and roles. Decode it locally and redact the token if it represents a real user or environment.
4. 4Redact with context preserved
   Replace only the sensitive value, not the surrounding field name. For example, keep Authorization: Bearer [redacted] so the reader still understands the failure path.

Examples

Authorization: Bearer <jwt>
X-API-Key: <value>
client_secret=<value>
https://example.com/download?X-Amz-Signature=<value>

Checklist

• Redact Authorization and Cookie headers.
• Inspect signed URLs and query strings.
• Decode JWTs locally before sharing.
• Remove emails and account IDs when they are not needed for debugging.
• Rotate credentials if a real secret was already shared.

Tools Used

• Smart ExtractSurface URLs, emails, JSON, and dates inside logs.
• JWT DecoderRead token claims before sharing.
• Base64 DecoderCheck encoded values locally.
• Regex TesterSearch logs for credential-like labels.

Frequently Asked Questions

Related Recipes