Skip to main content

Command Palette

Search for a command to run...

Audit logging is not authorization

Updated
•1 min read•View as Markdown
A
Practical lessons on auth, authorization, and access control.

Recording who did what is valuable. It is not the same as deciding whether they may do it.

Audit logs capture events after (or around) an action: actor, resource, timestamp, outcome. Authorization decides before the action whether that actor may perform that action on that resource. Mixing the two up leaves a clean trail of breaches you never prevented.

A common pattern: every mutation writes an audit row, so the team assumes access is "controlled." Attackers (or confused legitimate clients) still hit endpoints that never checked subject + action + resource. The log then faithfully records unauthorized reads and writes.

Do both, in order:

  1. Authorize first — evaluate the live permission for this subject, action, and resource (and tenant, if you are multi-tenant).
  2. Then perform the action if allowed.
  3. Then write the audit event, including denials when that helps detection.

Logs help forensics, compliance, and incident response. They do not replace an allow/deny decision at the enforcement point.