How it works
The explanation, with examples you can run.
What to log
Focus on events that change or test trust:
- authentication: logins, failures, lockouts, password resets, MFA enrolment and removal, new passkeys;
- authorisation: access denied (403/404 on objects), privilege and role changes;
- administration: config changes, user impersonation, feature flags on security controls;
- data: bulk exports, downloads of sensitive records, deletions;
- input that failed validation in suspicious ways, and errors from security controls.
For each: a timestamp in UTC, the actor (user or service ID, not their name), the action, the target, the result, source IP and user agent, and a request or trace ID to link it to other logs. Use structured logs (JSON) with consistent field names; the OWASP Logging Vocabulary offers a standard set of event names.
What never to log
Passwords (even wrong ones), session IDs, access and refresh tokens, API keys, private keys, full card numbers, and full personal records. Minimise personal data: log an internal user ID rather than an email address, and mask what you must keep. Redact at the logger, before anything leaves the process:
Press Run to see what your code prints, in order.
Runs in this browser, in an isolated frame with no access to this page. console.log, info, warn and error are shown; code runs as a classic script, so use an async function for await.
Deny-lists like this are a safety net. The stronger habit is to log chosen fields explicitly rather than dumping whole request objects.
From logs to detection
Ship logs off the host to a central system quickly, so an attacker on the machine can't delete them. Then decide what should wake someone up:
- many failed logins across many accounts from one source (credential stuffing), or many sources against one account;
- a successful login right after many failures, or from an unusual country plus an MFA change;
- bursts of 403 or 404 responses across sequential object IDs;
- a new admin, a disabled audit setting, or a large export outside normal hours.
Test that alerts fire, keep the number low enough that each is investigated, and write a short runbook for each.
Protecting the logs
Restrict read access, especially to anything containing personal data. Use append-only or write-once storage for audit trails. Set retention to what investigations and law require, and no longer.
Check yourself
3 questions. Get them all right to finish this topic.
0 of 3 right so far. Get all three to finish this topic.