Security Logging: What to Log, Fields, and Alerts

Last verified on Nov 8, 2026.

Security logging is recording the events you will need to detect an attack and reconstruct it afterward: who authenticated, who was refused, who changed what, and what happened to high-value data. If those events are not logged, a breach cannot be detected, and an investigation has nothing to work from. This guide covers which events to log, which fields each entry needs, what to keep out, how to protect the logs, and what to alert on.

Why It Fails in Practice

OWASP names this failure A09

The OWASP Logging Cheat Sheet adds a point worth repeating: infrastructure logs alone are not enough. The application has the most information about the user, their roles, and the context of an event, and infrastructure devices often cannot see it. Application code is the primary event source.

Events to Log

The cheat sheet says "where possible, always log" the following. Treat it as a baseline and size it to your risk, because it also warns that a blind checklist produces "alarm fog" that hides real problems.

OWASP's guidance on input validation failures is nuanced: treat them as suspicious events, not proof of an attack, because unexpected input can also come from misuse or client defects. Judge severity by repetition, correlation, and request context. For authentication failures, the signals are repeated failures on one account, failures from many addresses, and rapid bursts. The authentication anomalies guide covers detection in depth.

Audit trails for high-value transactions deserve stronger handling. OWASP A09 recommends integrity controls such as append-only database tables so entries cannot be tampered with or deleted. See audit log for the concept, and note that OWASP says process, audit and transaction logs are often collected for different purposes than security event logs and usually should be kept separate.

Fields Every Entry Needs

The cheat sheet states that logs must record "when, where, who and what" for each event:

Also consider recording the action, the object it targeted, the result status (success, fail, defer), the reason, the HTTP status code, the user agent, and a user type classification such as authenticated user or uptime monitor. The interaction identifier is worth the effort: it links every event from one user interaction, so you do not have to reconstruct the relationship later. It plays the same role as a request or correlation ID.

A structured entry that covers most of these looks like this:

{
  "timestamp": "2026-11-08T14:03:22.418Z",
  "event_type": "authz_failure",
  "severity": "warning",
  "security_event": true,
  "request_id": "9f3a1c52",
  "app": "billing-api",
  "app_version": "2026.44.1",
  "host": "billing-api-7d9c",
  "method": "GET",
  "path": "/v1/invoices/88123",
  "actor_id": "user_4412",
  "actor_role": "member",
  "src_ip": "203.0.113.50",
  "action": "invoice.read",
  "object": "invoice:88123",
  "result": "deny",
  "reason": "invoice belongs to a different account",
  "http_status": 403
}

Use a structured format. OWASP's log injection advice is to avoid unstructured text, where CR or LF characters in user input can forge entries, and to limit the size of user-supplied values in a log message. The structured logging entry covers the format.

What Never to Log

OWASP says that the following should usually not be recorded directly, and should instead be removed, masked, sanitized, hashed, or encrypted:

• Application source code
• Session identification values (consider a hash if you need to track session-specific events)
• Access tokens
• Authentication passwords
• Database connection strings
• Encryption keys and other primary secrets
• Bank account or payment card holder data
• Sensitive personal data and some forms of PII
• Data that you are not legally allowed to collect, or that a user has not consented to

It also notes that you should never exclude events from known users such as internal systems, search engines, pen testers, or uptime monitors. Add a classification flag to the entry instead. Mistakes here are common, and the secrets in logs guide covers finding and cleaning them. Redact at the source, where you own the data, and not only downstream.

Protecting the Logs

Logs are a target. The cheat sheet's list of attacks covers confidentiality (PII and secrets in logs), integrity (tampering), availability (flooding to exhaust disk, or to destroy other entries), and accountability (stopping writes or causing the wrong identity to be logged). Its protection guidance, which maps to these:

1. Tamper detection. Build in a way to know if a record was modified or deleted, and copy log data to read-only media as soon as possible.
2. Access control. Restrict and periodically review who can read logs, and record all access to them.
3. Transport. Use a secure transmission protocol when logs cross untrusted networks, for example syslog over TLS.
4. Separation. Prefer a separate partition for file-based logs, and a database account used only for writing logs with very restrictive permissions.
5. Log failure handling. Ensure that failures in the logging system neither stop the application nor leak information, and that logging cannot be used to exhaust disk space.
6. Time. Synchronize time across servers and devices. Where you cannot, such as on a user's phone, measure the offset or record confidence in the timestamp.
7. Retention and disposal. Do not destroy logs before the required retention period, and do not keep them beyond it. Legal, regulatory, and contractual obligations affect the period.

OWASP A09 also says logs must be held long enough to allow delayed forensic analysis. NIST SP 800-92, Guide to Computer Security Log Management (published September 2006), is the standard reference for the infrastructure and processes behind this, and the OWASP Logging Cheat Sheet points to it for further guidance.

Alerting and Verification

Logging without monitoring is a store of evidence nobody reads. Per OWASP, incorporate application logs into your central log management, make events available to the right teams, and alert the responsible people immediately on more serious events. What those alerts should catch is covered in access anomalies. Two checks are easy to skip:

• Detect when logging stops. A silent source looks the same as a quiet one. Alert when a source that normally emits security events produces none for a period.
• Test that attacks produce alerts. A09 lists penetration tests that fail to trigger any alert as a failure condition. Run a deliberate bad login burst or a forbidden request and confirm someone is told.

A starting query for the first alert is a count of authorization failures by actor over a short window:

SELECT actor_id, src_ip, count(*) AS denials
FROM app_logs
WHERE event_type = 'authz_failure'
  AND timestamp > now() - INTERVAL '10 minutes'
GROUP BY actor_id, src_ip
HAVING count(*) >= 20
ORDER BY denials DESC

OWASP also asks that logging be part of code review, testing, and security verification, with a check that the logging level is verified periodically and that changes to it follow change management. And take care that log-driven responses, such as account lockout, cannot be used to deny service to other users.

Security Logging with Sazabi

Sazabi, an AI-native observability and security platform, ingests the logs you send and lets you search them in plain language during an investigation. The Sazabi production checklist advises redacting secrets and sensitive fields at your log source or collector, and also offers a Redact sensitive data setting under Settings > Project that replaces emails, phone numbers, SSNs, card numbers, and secrets with placeholders before ingested logs are stored. For what to look for once the events are flowing, see security issues and logging best practices.