Insufficient Logging & Monitoring

What Is Insufficient Logging & Monitoring?

Insufficient logging and monitoring (OWASP API10:2019) is the failure to record and watch security-relevant events, so misuse goes undetected while it happens and cannot be reconstructed afterward. It is unusual among API weaknesses because the attacker often breaks no control at all: when access is authorized, an audit trail and an alert are the only things that can catch its abuse. This exercise puts you on both sides. As Bob, a support agent at Norvane, a digital bank, you use your own valid agent token to call the customer-lookup endpoint for one specific person you have no ticket for, and it returns her full profile, name, date of birth, SSN, address, and account balances, a single authorized call that looks exactly like routine support work. As Alice, the engineer who owns audit logging and monitoring, you learn weeks later that the customer's data is for sale, and Trust & Safety asks the one question that matters: which agent read this record, and when. You cannot answer it, because agent lookups are not audited, the application log records only that a lookup happened, with no agent, no customer, and no ticket. You open the lookup handler, see the empty log line, and ship the fix: an immutable audit event capturing the agent, the subject customer, the action, the ticket, the source IP, and a timestamp, written to an append-only sink, plus a monitored alert when a customer record is read with no ticket behind it. Replaying the ticketless lookup against the patched build, the read still returns 200 with the full profile, because a support agent is allowed to look up customers and the fix is accountability rather than prevention, but now the audit log names exactly who read the record under which ticket, and the ticketless access trips an alert. The exercise closes with quiz questions on why authorized access still has to be recorded, why a log with no actor or subject is not an audit trail, why the fix does not block the read, and what a good audit event must capture and feed.

What You'll Learn in Insufficient Logging & Monitoring

• Recognize insufficient logging and monitoring as a detection failure: sensitive access is not recorded with enough context, or not monitored, so misuse goes unseen and cannot be reconstructed
• Understand that authorized access (a valid credential used abusively) can only be caught by an audit trail and alerting, since no access control will reject it
• Distinguish it from access-control, data-exposure, and rate-limiting flaws; here a single authorized read is allowed and the missing control is attribution and visibility, not a block or a cap
• Apply the fix: emit an immutable audit event (actor, subject, action, ticket or reason, source IP, timestamp) to an append-only sink, and alert on suspicious access such as a sensitive read with no ticket
• Understand that the fix is detection and accountability, not prevention: a legitimate read stays allowed and still returns 200, while its abuse becomes attributable and alertable

Insufficient Logging & Monitoring — Training Steps

1. An agent with access

   Norvane is a digital bank. Its support agents look up customer accounts all day to handle tickets, using an internal console backed by the customer API. Bob is one of those agents, and he sells what he can reach. A fraud ring has paid him for a complete identity, so he has picked a Norvane customer with a large balance, someone he has no ticket for and no reason to touch. His access is real and his token is valid, so nothing he is about to do will be rejected. He opens the agent console to pull her record.

2. The lookup endpoint

   The customer lookup returns a full profile, and Bob's agent token is allowed to call it. Lookups are meant to reference the ticket the agent is working, but the API itself does not require one.

3. Pull the record

   Bob calls the lookup endpoint for the customer he was paid to steal, carrying his agent token and no ticket. It is a single, ordinary-looking request, the same call he makes dozens of times a day for real tickets, which is exactly why it will not stand out.

4. One person's whole life

   The token works. The server returned the customer's complete record.

5. Knowledge check

   You just watched a support agent pull one customer's entire identity with a valid token and no ticket. Lock in what kind of failure this is.

6. Which agent read this?

   You own audit logging and monitoring for Norvane's customer API. A customer's identity has been stolen and used for fraud, and the details could only have come from inside Norvane. Trust & Safety has emailed you with one question they can't answer on their own.

7. Read the application log

   Before touching code, you check what the API actually recorded. Tail the application log and look for anything that ties a lookup to an agent or to the customer whose data leaked.

8. No way to answer

   This is everything the API recorded about those lookups.

9. Open the lookup handler

   Open the customer-lookup handler and look at what it records when it serves a request.

10. Spot the flaw

    The handler checks the agent token, reads the customer, and returns the full profile. The one line it logs is the line you just saw: a note that a lookup happened, with none of the context that would make it an audit record.