The two previous exercises worked in the ideal scenario: we found the vulnerabilities and fixed them before they caused harm. Reality does not always grant that margin. In this case study we step back in time to a moment when BazarNube had not yet done that work, and one of the course's vulnerabilities -the orders IDOR, BZN-101- was still alive in production. The result was a personal data breach. Your role here is not the developer who fixes, but the analyst who investigates: reconstructing what happened, how it was detected, why it occurred and what would have to change so it does not happen again. We will apply the logging and monitoring from 03-11, the Top Ten classification and the incident response framework, all over a concrete narrative. By the end you will have not just the story of the incident, but the method for analyzing any other.

1. The incident narrative
2. Timeline of events
3. How it was detected: the role of logging and monitoring
4. Root cause analysis
5. Impact assessment
6. Incident response: containment, eradication and recovery
7. Lessons learned and the OWASP controls that would have prevented it
8. Common mistakes and tips
9. Exercises
10. Conclusion

Context. It is a Tuesday morning. Lucía gets a support alert: several customers are complaining about marketing emails from a competitor that mention recent orders they placed at BazarNube, with product and address details. Someone has data they should not have. SRE confirms there has been no database access and no known leaked credentials. The team opens a security incident.

The GET /api/orders/:id endpoint returned any order to any authenticated user, without checking ownership (the BZN-101 IDOR we remediated in 08-02). An attacker created a legitimate customer account, obtained a valid token and enumerated the order identifiers sequentially (/api/orders/1, /2, /3...), downloading the data of tens of thousands of other people's orders: name, address, products and email. There was no sophisticated "hack" or malware: just an authorization flaw exploited with a script and patience.

Reconstructing the chronology is the first deliverable of any analysis. It combines what the access logs, the application logs and the external reports say.

Two facts stand out: the extraction lasted four days and detection took another week, and it did not come from an internal system but from customer complaints. That delay is, in itself, a second finding as serious as the IDOR.

The incident was detected late and from the outside: BazarNube did not catch it, its customers did. That is the worst way to find out, and it is exactly the A09 (Security Logging and Monitoring Failures) we studied in 03-11. Analyzing why monitoring did not fire, the team found three gaps:

The lesson from 03-11 materializes here: having logs is not monitoring. BazarNube recorded the accesses, but no one correlated them and there were no alerts on anomalous behavior. A simple detector -"a user accesses more than N orders per minute"- would have fired an alert on Day 1, shrinking the exposure window from twelve days to minutes.

During the analysis, the team reconstructed what the evidence made visible. The access logs showed, in the raw, the unmistakable pattern of enumeration:

A single user=48213 walking consecutive IDs, mixing 200 (orders that exist) and 404, at a rate of several requests per second. The data was there from the first minute; what was missing was a rule to read it. That is why the costliest gap was not the absence of logs, but not acting on them. The alert rule added during recovery rests on exactly this signal.

A good analysis does not stop at "there was an IDOR"; it asks why it reached production and why it was not detected. The five whys technique helps:

1. Why did the data leak? Because the endpoint returned orders without checking ownership (IDOR, A01).
2. Why did the IDOR exist? Because object-level authorization was not a verified requirement; it was assumed that "whoever has the ID has permission."
3. Why was it not caught in development? Because there was no checklist-driven code review or authorization testing with two users (exactly what 08-01 covers).
4. Why did no alert fire when it was exploited? Because there was no monitoring of anomalous behavior (A09, 03-11).
5. Why did it take twelve days to come to light? Because the only "detection" was external: the affected customers.

The root cause is not a single line of code: it is the absence of several controls in a chain. The IDOR was the door; the lack of detection was the reason the damage grew. Fixing only the code would leave the second problem intact.

Quantifying the impact guides the response and the legal obligations.

The fact that payment was tokenized (a design decision from the 07-02 threat model) limited the damage: no card numbers were leaked. It is a concrete example of how a control applied in time reduces the impact of a flaw elsewhere. Defense in depth works even when one layer fails.

The team followed the classic incident response phases (at a high level; the forensic detail exceeds this defensive course):

• Containment (Day 12, 10:00). The /api/orders/:id endpoint is disabled (feature flag) to stop the leak immediately, even at the cost of breaking a feature. The attacker account's tokens are revoked and the logs are preserved as evidence. The priority is to stop the bleeding, not to fix it well yet.
• Eradication (Day 13). The definitive BZN-101 fix (the user_id filter from 08-02) is implemented and deployed, verified with two users. The rest of the endpoints are reviewed for the same class of flaw (remediate by family).
• Recovery (Day 13-14). The corrected endpoint is reactivated, closely monitored, and the missing order-access rate alert is added. It is confirmed that the extraction does not continue.
• Notification (Day 14). Affected parties and the data protection authority are informed per the legal obligation, with transparency about what data and what measures were taken.

Fast containment and transparent notification are as much a part of the response as the technical patch. Good incident handling reduces reputational damage almost as much as it prevents the technical one.

The closing of every incident is a blameless post-mortem that translates into concrete actions. These are BazarNube's:

The post-mortem's conclusion was uncomfortable: the IDOR had already been foreseen as a threat in the checkout threat model (07-02, the "Normal user forces another's order" row), but the mitigation was never implemented or verified. The failure was not one of knowledge, but of process: an identified threat that never became a verified requirement. That is precisely the gap the improvement exercise in the next lesson sets out to close.

• Hunting for culprits instead of causes. A post-mortem that points at "whoever wrote the line" does not fix the process and guarantees no one reports the next incident. Blameless culture.
• Stopping at the technical cause. "It was an IDOR" is only the first why. Without analyzing why it was not detected or why it reached production, the next incident will be identical.
• Confusing containment with a solution. Disabling the endpoint stops the leak, but it is not the fix. Contain fast, eradicate well, do not confuse the phases.
• Not preserving evidence. Deleting or rotating logs during the response destroys the information needed to understand the scope and for possible legal obligations.
• Tip: always measure the time to detection (from the attack to the moment you find out). It is the most neglected metric and the one that most reduces damage when it improves. An IDOR detected in minutes leaks tens of orders, not tens of thousands.

Exercise 1. Detection. Design the simplest alert rule that would have caught this attack on Day 1. State which signal it operates on, the approximate threshold and why it avoids drowning in false positives.

Exercise 2. Root cause. Apply the five whys to a different incident: passwords leak because they were stored in plaintext. Get at least to the fourth why and propose the OWASP control at each level.

Exercise 3. Impact and response. If payment had not been tokenized and card data had leaked, what would change in the impact assessment and in the notification obligations? List three differences.

Solution 1. The signal is the number of distinct orders a single user queries per unit of time. Rule: "alert if a user accesses more than, e.g., 50 different order_id in 5 minutes." It operates on the access log enriched with the authenticated user_id. It avoids false positives because a normal customer queries their few orders, not hundreds in sequence; the threshold is calibrated with the 99th percentile of legitimate traffic. Useful complement: detecting the sequential pattern of IDs, which is even more specific to enumeration.

Solution 2.

1. Why did the passwords leak? They were in plaintext in the DB. → Control: hashing with a slow algorithm (bcrypt/Argon2), A02 (03-02).
2. Why in plaintext? There was no requirement for secure credential storage. → Control: ASVS V2.4 as an acceptance criterion (M4).
3. Why was it not detected? No code review or SAST flagged the insecure storage. → Control: review + SAST in the pipeline (07-03).
4. Why did no one prioritize it? Credential storage was not in the threat model. → Control: threat modeling of the authentication flow (07-02).

Solution 3. Three differences: (1) Data affected now includes financial data, raising the severity to critical and the potential impact (direct fraud). (2) Regulatory framework: PCI-DSS obligations apply in addition to data protection, with notification to the card brands and possible penalties. (3) Response: card reissuance and fraud monitoring would have to be forced, a much larger scope and cost. It illustrates why tokenization (not storing the PAN) is one of the highest-return design decisions.

We have analyzed a complete BazarNube incident: its chronology, the late and external detection that exposed a monitoring failure as serious as the vulnerability itself, the chained root cause the five whys revealed, the impact bounded thanks to tokenization, and an orderly response of containment, eradication and recovery. The underlying lesson is that an incident rarely arises from a single flaw: it arises from a known threat the process never turned into a verified control, and from a detection that did not exist. BazarNube came out of this with a list of actions and one certainty: it needs to mature its security systematically, not incident by incident. That is exactly what we will see in the module's final lesson, 08-04: how the application moves from this reactive, insecure state to a mature one, applying in an integrated way everything learned in the course.