Security Logging & Alerting Failures: From an Event to a Response

Security Logging & Alerting Failures is the ninth category in the OWASP Top 10:2025. The emphasis on alerting helped me organize this part of my PWPA notes.

A security-relevant event can be recorded without anyone noticing it in time to respond. The reading connects the event, the record, the detection rule, and the action that follows.

Start with a question the logs need to answer

Imagine a hypothetical account service receiving an unusual burst of failed login attempts. Some attempts are followed by successful logins and changes to recovery details.

If only the final successful login is recorded, important context is missing. If all the events are recorded but never brought together, the pattern may still be missed.

The useful starting question is what the application needs to recognize. Examples might include repeated authorization failures, unusual account changes, or access to a particularly sensitive function. OWASP's A09 guidance connects these events to monitoring, escalation, and response.

Give the event enough context

A message saying “something failed” may be difficult to investigate.

A useful security event identifies when it happened, the action involved, its outcome, and the relevant account or resource where appropriate. A request or interaction identifier can help connect events across services without recording the full contents of every request.

Consistent formats and timestamps make those records easier to use. The application often knows details that a basic web-server access log cannot provide, such as whether a business operation was rejected by an authorization check.

Avoid creating another store of secrets

Logs need deliberate limits. Passwords, access tokens, cryptographic keys, and usable session identifiers should not be copied into ordinary logs. Personal data should be limited to what is needed and handled according to the system's privacy and retention requirements.

Untrusted values also need safe handling in the logging format. Otherwise, crafted input may make a log misleading or attack the tools used to process and display it.

Access to logs, their transmission, and their storage all need protection. The OWASP Logging Cheat Sheet covers these concerns alongside the choice of events to record.

An alert needs an owner and a next step

An alert should make it reasonably clear what happened, why it matters, and where to investigate.

It also needs to reach someone who can act. That raises practical questions: who owns the response, what should they check, and when should they escalate?

Too many low-value alerts can make important ones harder to notice. A useful detection rule therefore needs review against both normal activity and the behavior it is intended to identify. Thresholds and response instructions may need to change as the application changes.

Test the path all the way through

For a controlled test in an authorized environment, I would want to follow an agreed scenario from the application event through to the expected response.

Was the event generated? Did it reach the logging system with the needed context? Did the relevant rule identify it? Did the alert reach the intended recipient, and were the response instructions usable?

The test should have a defined expectation. A scanner running does not mean every request should page someone, but the security scenarios chosen for detection should produce the intended evidence and alerts.

The logging system's own failures deserve attention too. A full disk, disconnected collector, or broken notification route can interrupt the process.

My takeaway

This category gives me a way to connect application behavior to incident response. Useful logs preserve the information needed to understand events, and useful alerts bring the right events to someone's attention in time to act.

The final category in this series covers how the application behaves when normal operation breaks down.

Sources and further reading