An incident responder pulls up the access logs for a suspicious account and finds exactly what they need to reconstruct the timeline — except the request bodies were logged in full, and sitting in plain text in that same log file are the API keys, passwords, and card numbers that were part of the very requests under investigation. The log that was supposed to help contain the incident has just become a second, entirely separate breach, potentially larger than the one being investigated, because now every engineer with log access — a much wider group than the group with database access — can see raw credentials that were never supposed to leave the request they were part of.
This is not a rare misconfiguration; it is the default outcome of logging frameworks that capture request and response bodies for debugging convenience, deployed without anyone deciding what belongs in a log and what categorically does not. Good audit logging is not 'log everything and figure out access control later' — it is a deliberate decision, made before the first line of logging code is written, about exactly what facts an audit trail needs to answer 'who did what, when, to what, with what outcome,' and a hard rule that nothing beyond those facts, especially not secrets or full PII, ever gets written.
Analogy🏏Cricket
🏏 Think of it like cricket: A stadium's CCTV and access-log system exists to answer a specific, narrow set of questions if something goes wrong — who entered which gate, at what time, using which credential — and it is deliberately designed to answer exactly that and nothing more; it does not, for instance, record and permanently store the private conversation two stewards had while checking a ticket, even though a microphone sitting right there could technically capture it. A ground that logged everything a microphone could pick up, on the theory that more data might be useful someday, would create a searchable archive of private conversations that has nothing to do with the actual security purpose and everything to do with a new liability the ground never needed to create. Just as the access log is scoped to exactly the facts an investigation would need — who, where, when — and no more, an API audit log should be scoped to exactly the facts an incident investigation needs, not a full recording of every request's raw contents. Just as capturing private conversations 'just in case' creates a liability with no corresponding security benefit, logging raw request bodies containing credentials or full PII 'just in case it's useful for debugging' creates a liability — a secondary source of secrets — with no corresponding audit benefit. The insight is that a good audit trail is defined by what it deliberately excludes as much as by what it captures.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.