While debugging a Meraki integration, a developer enables a ‘log everything’ mode that prints Authorization headers and API keys. What makes that logging strategy unsafe?

Tokens, refresh material, and secret-store payloads must be redacted from application logs. Credentials that land in log aggregators become broadly readable incident data and violate least privilege for anyone with search access across the municipal logging estate. Treating Meraki keys as safe to log because Dashboard shares are “read-only by default” confuses authorization scope with confidentiality—read-only keys still grant access and must not be archived in plaintext. Duplicating Authorization headers into INFO lines for every successful 200 response systematically exfiltrates bearer material into long-lived storage that outlasts the session. Placing secret material in DEBUG while keeping ERROR “clean” fails because DEBUG is frequently enabled during outages and still ships to the same collectors. Exam caveat: framework access logs and reverse proxies may log headers by default—disable or redact Authorization, API key, and cookie fields at those layers too, not only in application code. Operational check: authenticate a staging call with a known test token, search the log backend for substrings of that token, and confirm redaction markers appear instead of the raw secret value.