You're On Call. It's 02:13. Was This a Breach?

At 02:13, a customer reports seeing another company's order.

The application is healthy. No deployment failed. Your monitoring dashboard is green.

You have the following five log entries. What can you conclude?

This is a fictional investigation exercise. All accounts, orders, times and events below are invented.

02:10:04 INFO  login.success user=alice tenant=north request=r10
02:11:18 INFO  GET /api/orders/o-814 actor=alice status=200 request=r11
02:11:52 WARN  image.resize.failed asset=logo-6 request=r12
02:12:09 INFO  GET /api/orders/o-815 actor=alice status=200 request=r13
02:13:02 INFO  support.ticket.created category=wrong-order request=r14

You also have this simplified handler:

const order = await db.order.findUnique({
  where: { id: req.params.id }
});

if (!order) return res.sendStatus(404);
return res.json({ id: order.id, items: order.items });

Assume authentication has already succeeded. Tenant authorization is the question under investigation.

Pause before declaring a breach

An HTTP 200 does not identify the owner of an order. It does not show the response body. The log excerpt also does not tell us whether another layer applied an authorization policy.

The customer report and handler justify investigation. They do not establish how many users or records were affected.

My next questions would be:

1. Which tenant owned o-815 at the time?
2. What access was Alice entitled to at the time?
3. What data did request r13 return?
4. Was an authorization check applied elsewhere?

The image-resizing warning currently has no demonstrated connection to the report.

Reveal the additional evidence

In this fictional scenario, the investigator confirms that o-815 belonged to tenant south. Alice had access only to tenant north. A retained trace confirms that r13 returned the order items, and code review finds no intervening tenant authorization check.

That supports one confirmed cross-tenant disclosure in this exercise. It does not establish bulk extraction, intent, or the total number of affected orders.

Repair the rule, then verify the behavior

For this example, order retrieval should be constrained by both the requested identifier and the tenant the caller is authorized to access. That tenant context must come from trusted, verified membership information.

Regression tests should cover an allowed request, a cross-tenant request and a nonexistent order. They should also verify the permitted response fields.

Incident handling would additionally require preserving relevant evidence, assessing the exposure and coordinating containment under the organization's process. A code patch alone does not complete the investigation.

The skill this exercise tests

It is easy to jump from “suspicious log” to “confirmed breach,” or from “we found one request” to “only one request happened.”

The harder skill is keeping observations, hypotheses and conclusions separate, then selecting the evidence that resolves uncertainty.

I am building Breachloom, a browser-based security practice platform with investigation and code-repair exercises. This article is a standalone fictional case, not a claim that this exact scenario is playable there.

Before opening the reveal, which evidence would you request first — and what would it establish?