Know where secrets appear
Secrets appear in environment variables, Authorization headers, command-line arguments, database URLs, webhook signatures, cloud configuration, build output, request dumps, and exception messages.
Some values are obvious because the key name says password or token. Others are only recognizable by a provider-specific prefix or by their length and randomness.
Keep the label, remove the value
For troubleshooting, the location of a secret is often useful while the secret itself is not. Keep text such as Authorization: Bearer [SECRET] or API_KEY=[SECRET].
Avoid partial masking in public content. Showing the first or last characters can help internal identification, but it also creates unnecessary exposure and may reveal which service issued the key.
Rotate instead of relying on deletion
Once a real secret leaves an approved location, assume it may have been copied. Revoke it, create a replacement, update dependent services, and verify that old access no longer works.
Check repository history, CI logs, ticket attachments, chat exports, screenshots, and copied commands. The same credential may exist in more than one place.
Use synthetic examples for support
A minimal reproduction should use fake credentials that cannot access anything. Preserve the character class or approximate shape only when the format itself is relevant to the bug.
For example, use sk_test_[REDACTED] rather than a real production key. Explain the provider and environment separately.
Final review checklist
- Authorization headers checked
- Environment and connection strings checked
- Screenshots and attachments checked
- Exposed values revoked
- Examples use non-working synthetic secrets