Security Logging and Monitoring: What to Log and When to Alert
Practice4 minInnovialabs editorial team
In short
Log who did what, when, from where and with what result for logins, permission changes, admin actions and denied access; never log passwords, tokens or card data; keep logs centrally and alert on patterns like brute force, new admins and mass exports.
The short answer
Security logs exist to answer three questions after something goes wrong: who did it, what exactly happened and when it started. For that you need:
- a fixed list of security events logged by the application itself;
- structured records with the same fields everywhere;
- central storage that attackers and regular admins cannot quietly edit;
- a small set of alerts that someone actually reads.
Events every app should log
Authentication
- successful and failed logins, logouts;
- 2FA enabled, disabled, failed codes;
- password changes and reset requests;
- account lockouts and unlocks.
Authorization and access
- denied access (403) to endpoints or objects;
- attempts to access other users' records;
- API keys created, used from a new place, revoked.
Administrative actions
- roles and permissions granted or removed;
- users created, blocked, deleted;
- changes to payment, security or integration settings;
- impersonation ("log in as user") by support staff.
Sensitive data operations
- mass exports and bulk downloads;
- viewing personal data in bulk;
- deletion of many records at once.
System signals
- input validation failures at unusual rates;
- webhook signature failures;
- application errors related to security checks.
What a good record looks like
Use structured logs (JSON) with consistent fields:
{
"ts": "2026-03-14T09:21:07Z",
"event": "auth.login_failed",
"actor_id": null,
"target": "user:4812",
"ip": "203.0.113.17",
"user_agent": "Mozilla/5.0 ...",
"request_id": "a1b2c3",
"result": "failure",
"reason": "bad_password"
}
Key fields: time in UTC, event name, who (user or service), on what, source IP, result and a request ID to link the log with application traces.
What must never be logged
- Passwords, including wrong passwords from failed attempts — they are often the real password with a typo.
- Session tokens, JWTs, API keys, reset links, OTP codes,
Authorizationheaders and cookies. - Full card numbers and CVV. If needed, log only a masked form.
- Secrets from environment variables and configs.
- Excess personal data: passport numbers, full request bodies with personal fields.
Practical protection: an allowlist of fields to log instead of dumping whole request objects, plus automatic masking of known sensitive keys in the logger.
Storage and retention
- Send logs to a central system outside the application server, so a compromised server cannot erase its tracks.
- Restrict access to logs; log access to logs.
- Keep timestamps synchronized (NTP) across servers.
- Retention depends on the law, contracts and industry standards that apply to you, such as PCI DSS for card payments, plus how long attacks can go unnoticed. Logs contain personal data, so personal data laws also limit how long and where they are stored. Keep recent logs quickly searchable and older ones in cheaper archive storage.
Alert rules that catch attacks early
| Rule | What it may indicate |
|---|---|
| Many failed logins for one account or from one IP in a short window | Brute force or credential stuffing |
| Successful login after a series of failures | A guessed password |
| Login from a new country or device for an admin | Stolen credentials |
| New admin or role escalation | Persistence after a breach |
| 2FA disabled on a privileged account | Takeover preparation |
| Unusual volume of exports or record views | Data theft |
| Spike in 403 responses from one user | Probing for IDOR or misconfigured access |
| Many webhook signature failures | Spoofing attempts |
Rules for setting alerts:
- Few and actionable: each alert should have an owner and a short "what to do" instruction.
- Tune thresholds to your normal traffic; noisy alerts get muted and then ignored.
- Send critical alerts to a channel that people watch, not just to an email folder.
- Test alerts regularly by triggering them on purpose.
Common mistakes
- Logging only errors, not successful security-relevant actions.
- Logs only on the same server as the app.
- Free-text messages that cannot be searched or aggregated.
- Debug logging left on in production with full request bodies.