Monitor web abuse

A prevented request still tells you an attack is underway. A denied read is a normal event on its own, but a pattern of them is evidence. The goal is to capture that signal without recording the dangerous payload or the credential someone tried.

Log the security-relevant fact, and be careful what you put in the fields.

log.warn('authz.denied', {
  actorId: req.user?.id,        // safe identifier, not the raw token
  action: 'note.read',
  targetId: req.params.id,
  outcome: 'denied',
  ip: req.ip,
})

Alert on patterns, not on every denial

One failed object read is common. Five hundred failures across sequential note IDs from one session is evidence of enumeration. Aggregate before you alert.

alert: object-enumeration
when:  authz.denied grouped by actorId
       count > 100 within 5m
       across > 20 distinct sequential targetIds
route: security-oncall  (link: dashboard + runbook)

Aggregate repeated authorization failures, rate-limit decisions, upload rejections, outbound-fetch blocks, and admin changes. Alerting on every denial overwhelms responders and buries the useful pattern in routine noise.

Give responders enough context to act safely: a safe actor id, the operation, the target pattern, time, and outcome, plus an owner and a link to investigate. An alert with no owner and no next step becomes noise that people learn to ignore.

Watch the same way for unusual data movement and configuration changes, not only failed reads. A sudden large export, a new admin grant, or a burst of blocked outbound fetches each deserves its own aggregated signal.

Generate normal mistakes and a burst of sequential cross-user reads in a test environment. Show the normal traffic stays below the threshold, the burst creates one actionable alert, and the alert contains an owner and investigation link.