Checklist

OWASP logging and monitoring checklist

A checklist based on the OWASP Logging and Monitoring Cheat Sheets. Use this when designing or reviewing application logging, audit trails, and alerting.

https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html

36 items
7 sections
Reusable template

Your progress

0 of 36 items complete

complete

Saved in your browser. Sign in to Checksy to share progress with your team.

What to log

All authentication attempts (success and failure)
All access control denials and privilege escalations
All input validation failures on the server
All session lifecycle events (create, renew, expire, logout)
All changes to user roles, permissions, and secrets
All high-value business actions (payment, export, deletion)
All admin actions, especially those affecting other users

What NOT to log

No passwords, even hashed, in normal application logs
No session tokens, API keys, or JWTs
No full payment card numbers (mask all but last 4)
No personal data beyond what is required for the event
No request bodies for endpoints that accept secrets

Log entry content

Each event has a UTC timestamp from a synchronized clock
Each event records who (user/service ID) and from where (IP, user agent)
Each event records what (action) and on which resource
Each event includes an outcome (success/failure) and reason
Each event has a correlation ID linking related requests

Log integrity and storage

Logs are sent to a central system the application cannot delete
Logs are write-once or append-only at rest
Log shipping is monitored for gaps and failures
Log retention matches policy and legal requirements
Logs are encrypted in transit and at rest

Log injection and encoding

User-supplied data in logs is encoded to prevent log forging
Newlines and control characters in user input are escaped
Structured logging (JSON) is preferred over free-form strings
Log viewers render entries safely (no XSS in log dashboards)

Monitoring and alerting

Alerts fire on auth failure spikes and account lockouts
Alerts fire on access control denials in bursts
Alerts fire on changes to critical configuration or roles
Alerts have an owner and a documented response runbook
Alerts are routinely reviewed for false positives and gaps

Incident response

An incident response plan exists and is tested at least yearly
Roles and contact details are kept current
Logs and metrics are sufficient to reconstruct an incident timeline
Post-incident reviews produce concrete follow-up actions
Customers and regulators can be notified within required timeframes

Run this checklist for real

Save your progress, share with your team, and turn this into a reusable template. This helps you track how you improve over time.

Use in Checksy More checklists