Log useful security events

If an incident happens, we need evidence. A security log should answer who did what, when, from where, and whether it succeeded — for every event that matters.

The events that matter are stable across most products: authentication (logins, failures, resets), authorization denials, configuration changes, sensitive data access, and administrative actions. If a support engineer exported all users yesterday, the log should say so.

The shape of a useful event

Structure beats prose. Use stable event names, timestamps, actor and target identifiers, outcomes, and a request correlation ID:

{
  "event": "auth.login.failed",
  "time": "2026-08-03T14:12:09Z",
  "actor": "user_9412",
  "source_ip": "203.0.113.7",
  "outcome": "failure",
  "reason": "bad_password",
  "request_id": "req_77af0c"
}

The request_id is the thread that ties one user action together across services. The stable event name is what makes queries possible:

grep '"event":"auth.login.failed"' app.log | wc -l
# counting guesses is a one-liner when the name never changes

Under-logging and over-logging fail together

Watch the failure from both sides. A login event that records “failed” but no safe account identifier, source, or request ID gives responders nothing during an attack — they cannot separate one mistyped password from thousands of guesses across hundreds of accounts. The event existed and answered no questions.

The reflex fix — log everything about the request — creates the opposite disaster. Logging the submitted password would add evidence by creating a second breach: every failed login stores a string that is probably almost the user’s real password, readable by everyone with log access.

Never log passwords, raw session tokens, reset links, private keys, or personal data you do not need. Record enough context to correlate behavior without storing credentials. Identifiers and fingerprints, not secrets.

Logs are themselves a target

An attacker who can edit logs erases their own trail. An attacker who can read them harvests whatever leaked into them. Restrict who can read and modify logs, and define retention deliberately: long enough to investigate an incident you discover late, not so long that the archive itself becomes a liability.

Trigger one successful login, one failed login, and one denied cross-user read in your own app. Verify the three events share stable names and request IDs, then search the captured output for passwords, session tokens, and reset links. Empty search results are the pass condition.