What to log
You cannot detect, investigate, or prove an incident you never logged. Capture every auth, access, and admin event with enough context to reconstruct who-did-what-to-what — and make sure secrets, tokens, and full PII never land in the log.
It’s 2 a.m. and the on-call is staring at a vendor email: “credentials from your tenant were used to export 40k records last Tuesday.” She opens the logs. Application logs show 200s and 500s — useless. The access log has IPs but no user ids. There’s no record of who hit the export endpoint, which records, or when the session was created. The breach is real; the evidence is gone. Industry breach reports keep putting the median attacker dwell time — from intrusion to detection — at multiple weeks, and the single biggest reason it’s not minutes is that the events that would have lit up on day one were never written down. You can’t alert on, investigate, or prove an action you never logged.
By the end of this lesson you’ll know exactly which security-relevant events to capture, what context turns a log line into evidence, and what must never be allowed to land in a log.
Logging is the detection substrate
Before you can detect an attack, contain an incident, or prove what happened in a post-mortem, the event has to exist somewhere durable. A log is not a debugging convenience that you bolt on for developers — it is the raw material every downstream defensive capability is built from. Your SIEM correlates log lines. Your alerts fire on patterns in log lines. Your incident timeline is a sequence of log lines. NIST SP 800-92 frames this directly: log management is the discipline of generating, transmitting, storing, and analyzing the records that let you reconstruct security-relevant activity. If the event isn’t captured at the moment it happens, no amount of clever tooling after the fact can recover it.
This is why “what to log” is a security-architecture decision, not a developer-convenience one. The attacker’s actions map onto observable techniques — MITRE ATT&CK catalogs them: credential access, privilege escalation, data exfiltration, defense evasion. Every one of those leaves a trace if and only if the right event was instrumented. The defender’s job is to make sure each meaningful action produces a signal you can later detect on. Under-log and you’re blind; the attacker operates in silence for weeks. Over-log the wrong thing — dump raw request bodies, full headers, secrets — and you’ve built a second breach: a giant searchable store of credentials and PII that is now itself a target.
What to capture: the security event classes
Skip the noise. The events worth their storage cost are the ones an investigator or an alert rule actually needs. In rough priority order:
| Event class | Examples | Why it matters |
|---|---|---|
| Authentication | Login success/failure, logout, MFA challenge, password reset, token issue/refresh | Brute force, credential stuffing, account takeover all show here first |
| Authorization | Access denied (403), privilege use, role/permission change, ownership-scoped fetch | A burst of 403s is recon; a granted privilege change is escalation |
| Admin & config | User create/delete, role grant, API-key mint, feature-flag flip, security-setting change | High blast radius; first stop for insider and post-compromise abuse |
| Sensitive data access | Bulk export, PII read, report generation, download of regulated records | Exfiltration is “normal” reads at abnormal volume — invisible without it |
| Input & integrity | Validation rejects, signature failures, rate-limit trips, anomalous payloads | Probing and injection attempts surface as a spike of rejects |
| Log integrity | Log start/stop, gaps, clock changes, audit-pipeline errors | ”Defense evasion” — attackers clear logs; absence of logs is a signal |
Notice the pattern: you log the security-relevant decision, not every line of business code. A successful product browse is noise. A 403 on /api/admin/users is an authorization decision worth recording, because a burst of them is someone mapping your permission model. The senior reflex is to instrument the choke points — the auth layer, the authorization middleware, the admin handlers, the data-export paths — once, centrally, so coverage doesn’t depend on every feature author remembering to add a log call.
Context is what makes a line evidence
A log that says error: forbidden is worthless three weeks later. The line has to answer the investigator’s five questions: who, what, to-what, when, from-where. That means a structured event (JSON, not a free-text string you’ll later regex) carrying at minimum: a stable actor id (user id or service principal — never just a display name), the action, the target resource and its id, an authoritative server-side timestamp, the source IP and user-agent, a correlation/request id to stitch the request across services, and the outcome (allowed/denied, success/failure). A 403 with no actor id and no resource id tells you something was blocked; it doesn’t tell you the same account just got blocked 400 times in 90 seconds across 400 different invoice ids — which is the actual signal.
The hard rule: what must never land in a log
Logs leak. They’re shipped to third-party SIEMs, replicated to cheap cold storage, read by support engineers, indexed for full-text search, and retained for years. So a secret in a log is a secret with the widest possible blast radius and the longest possible lifetime. Treat the log as semi-public, and never write: passwords (even “wrong” ones — they reveal the user’s pattern and often the right one mistyped), session tokens, API keys, JWTs and bearer headers, full card numbers (PCI-DSS forbids it outright; it bans storing the full PAN in logs and never permits the CVV at all), and unmasked PII beyond what the investigation needs — government ids, full health records, raw Authorization headers. The mechanism that causes this is almost always over-capture: someone logs the entire request body or all headers “to be safe,” and now every password and token that ever flowed through is sitting in Elasticsearch.
▸Why this works
Why is logging “the whole request to be safe” the single most common way to turn a log store into a breach? Because the request body and the Authorization header are exactly where the secrets live — that’s their job. A blanket log.info(req.body) or a middleware that dumps all headers captures passwords on the login route, full card numbers on checkout, and bearer tokens on every authenticated call, in plaintext, fanned out to every place the log later travels. The fix is to log fields you chose, never whole objects: an allowlist of safe attributes, with redaction (****1234, Bearer ***) applied at the logging boundary so a sensitive value can’t slip through even if a new field appears upstream. Allowlist what’s safe; never blocklist what’s dangerous — the blocklist always misses the next field someone adds.
Retention: long enough to investigate, short enough to be safe
Retention is a real tradeoff, not a “keep everything forever” default. Keep logs too short and you can’t investigate a breach you only learn about months later — which is the normal case, given dwell times measured in weeks and disclosures that arrive even later. Keep them too long, in the wrong form, and you’re hoarding a growing pile of PII that costs money to store, expands your attack surface, and collides with data-minimization law (GDPR’s storage-limitation principle). The senior answer is tiered: hot, queryable storage for recent activity (often ~90 days) so detection and live investigation are fast; cheaper immutable cold/archive storage for the longer window your compliance regime demands (often a year or more for audit and regulated data); and aggressive minimization or pseudonymization of PII inside those logs so the archive is useful for forensics without becoming a liability. And critically, make security logs append-only / tamper-evident — an attacker’s standard move after compromise is to delete the logs that would expose them, so the store an investigator relies on must be one the attacker who reached the app server can’t quietly rewrite.
Your login endpoint must produce useful security logs. A teammate proposes `log.info('login attempt', req.body)` so 'nothing is lost.' Pick the correct approach.
An attacker exfiltrates 40k records over a normal-looking bulk-export endpoint. Which logging gap most directly let it stay invisible for weeks?
Why prefer an allowlist of safe fields over a blocklist of forbidden ones when deciding what a log line may contain?
Order these from highest to lowest priority for a brand-new service's security logging:
- 1 Authentication events (login success/failure, MFA, token issue)
- 2 Authorization decisions (403s, privilege use, role changes)
- 3 Admin & config actions (user/role/key changes)
- 4 Sensitive-data access (bulk export, PII reads)
- 5 Input/integrity rejects (validation, rate-limit trips)
- 01Which classes of events must a service log to be defensible, and what context turns a log line into usable evidence?
- 02What must never be written to a log, why does it usually happen, and how do retention and tamper-resistance fit in?
You cannot detect, investigate, or prove an incident you never logged — logging is the substrate every downstream defensive capability is built on, which is why what to log is a security-architecture decision, not a developer convenience. Capture the security-relevant decisions: authentication, authorization, admin/config, sensitive-data access, input/integrity, and log-integrity events, instrumented once at the choke points so coverage doesn’t depend on every author. Make each event structured and answer who/what/to-what/when/from-where plus the outcome, so a bare 403 becomes a line a SIEM can correlate into a brute-force or recon signal. Then hold the hard line on what must never land in a log: passwords, tokens, keys, JWTs, full card numbers, and unmasked PII — the leak almost always comes from over-capture (logging the whole request body or all headers), so allowlist safe fields and redact at the boundary rather than blocklisting dangerous ones. Tier your retention (hot for detection, cold-immutable for compliance, PII minimized throughout) and make the store append-only and tamper-evident, because the attacker who reaches your server will try to erase the very logs you need. Next time you write a handler, ask: does this emit a structured event an investigator could act on — and is there any way a secret could ride along into the log?
Practice
Start at the top. Tasks go easiest → hardest: recall a fact, apply it to a case, then a senior-level stretch. Open one, attempt it, then reveal.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.
Apply this
Put this lesson to work on a real build.