What Sensitive Data Should Never Be Stored in Logs?

Most sensitive data in logs isn't there because someone decided to log it - it's there because a broad logging statement captured more than intended. This is a working checklist of what to specifically watch for, and why each category is worth treating differently from ordinary debug output.

Credentials and authentication material

• Passwords, in any form - plaintext or hashed. A hash is still one offline attack away from being useful, and there's simply no reason to log it.
• API keys and access tokens - a leaked key found in a log is functionally identical to a stolen key.
• JWTs - the signature portion can be used to impersonate the token's owner until it expires.
• Session cookies and session IDs - these can often be replayed to hijack an active session.
• Database connection strings - these frequently embed a username and password directly in the URL.
• Cloud provider credentials (access keys, secret keys) - these can grant broad infrastructure access if found.
• Private keys - anything resembling a PEM block (-----BEGIN PRIVATE KEY-----) should never appear in a log.

Personal and identifying information

• Full names combined with other identifying context
• Email addresses
• Phone numbers
• Physical addresses
• Government-issued ID numbers
• Dates of birth

None of these are automatically catastrophic on their own, but they add up - and depending on your industry, several data-protection regulations place specific restrictions on how personal data can be stored and retained, which extends to logs whether or not that was the intent.

Financial information

• Full credit card numbers
• CVV codes
• Bank account and routing numbers

Payment data has its own compliance framework (PCI DSS) that treats logging full card numbers as a direct violation, regardless of whether the log is ever shared externally.

Request internals that hide credentials

• Authorization headers - these often contain a Bearer token or Basic auth credentials directly
• Full cookie headers
• Query strings with embedded tokens (?api_key=...) - these are easy to miss because they don't look like a credential field
• Webhook signing secrets

A quick reference table

A practical checklist before sharing a log

• No Authorization or Cookie header values are visible in plaintext
• No API keys, tokens, or connection strings are present
• No full card numbers or CVVs are present
• Email addresses and phone numbers are masked or removed if the log is leaving internal systems
• Field names in structured (JSON) logs have been checked, not just the values

Related reading

For the step-by-step process of actually cleaning a log once you've identified what needs to go, see How to Remove Sensitive Data from Logs: A Step-by-Step Guide.

Summary

The categories worth watching for are consistent across almost every codebase: credentials, personal data, financial data, and the request internals (headers, cookies, query strings) that quietly carry all three. Treating this as a fixed checklist - rather than relying on catching it by eye each time - is what keeps sanitization consistent under time pressure.