Insufficient Logging

The application doesn't record enough detail about security-relevant events - failed login attempts, privilege changes, access to sensitive records - to reconstruct what happened during an incident after the fact. This is a detection-and-response gap rather than an exploitable bug in itself: it doesn't let an attacker do anything they couldn't otherwise do, but it means a real attack, once it happens, is much harder to investigate, scope, and respond to.

What gets logged and where those logs are stored is entirely internal to the application's backend - none of it is observable by sending requests and reading responses from outside.

Reviewing the application's actual logging configuration against a standard like the OWASP Logging Cheat Sheet, and checking whether security-relevant events (auth failures, permission changes, sensitive-data access) are captured with enough context to support incident response.

Tip: This gap is found by auditing what actually gets logged against what a real incident-response investigation would need — walk through a hypothetical compromise scenario and check whether the current logs could actually answer "what happened, when, and to what."

Real-World Impact

Insufficient logging doesn't cause a breach on its own, but it determines whether one gets noticed, understood, and contained once it happens. Without adequate logging of authentication events, access to sensitive resources, and administrative actions, an organization frequently only learns about a compromise from an external party, a customer, a researcher, law enforcement, and by then has no reliable record of what the attacker actually did, how long they had access, or what data they touched.

The practical cost shows up during incident response specifically: investigation takes substantially longer, scope determination becomes a matter of inference rather than evidence, and regulatory notification obligations (which often require specifying what data was affected) become difficult or impossible to satisfy with confidence.

This is also a compliance-relevant gap in its own right — most security and privacy frameworks (PCI DSS, SOC 2, HIPAA, and similar) explicitly require logging of security-relevant events, independent of whether an incident has ever occurred.

Prevention and Secure Design

Preventing Insufficient Logging takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Log every security-relevant event, not just errors. Authentication attempts (success and failure), access to sensitive resources, administrative actions, and privilege changes should all generate a log entry as a baseline.

Include enough context to actually investigate later. A log entry needs the who, what, when, and from-where — a bare "action performed" entry without an actor, timestamp, and source is close to useless during an investigation.

Centralize logs somewhere an attacker who compromises the application can't also delete them. Ship logs to a separate, append-only or write-once system rather than only storing them on the same host that could be compromised.

Alert on the events that actually matter, not just collect them. Logging without monitoring still means the incident is only discovered after the fact — pair logging with alerting on the specific patterns that indicate active exploitation.

Retain logs long enough to matter. Many breaches aren't discovered for weeks or months — a retention window shorter than realistic detection timelines defeats the purpose of logging in the first place.