CraveCart's website lets customers search past orders by typing a restaurant name into a search box. Last Tuesday, a QA tester was experimenting with the search field and typed in some unusual characters just to see what would happen. Instead of an error message, the search returned thousands of customer records that had nothing to do with the search term.

The security team pulled the application error log to figure out what happened. It turns out the search box passes whatever a user types directly into a database query without checking it first — a textbook application vulnerability. An attacker who understands how the search box is built could use the same trick — a SQL Injection — to pull sensitive data like customer emails, phone numbers, and payment tokens straight out of the database. If the search box also had a way to modify records, the same flaw could let an attacker perform privilege escalation and gain far more access than a normal customer should ever have.

Following the search-box incident, CraveCart's new IT Security Manager ordered a full access control audit. The goal: make sure every employee's account permissions match what their job role actually requires — a system called Role-Based Access Control (RBAC). Employees should only ever have the permissions needed to do their specific job, following the principle of least privilege.

The audit uncovered a problem. Several accounts had been granted far more access than their role required, often because it was "easier" when the account was first set up, and no one ever revoked the extra access. This is exactly the kind of gap that managerial controls — clear policies about who approves and reviews access — are supposed to catch. CraveCart also classifies its data by data classification level (Public, Internal, Sensitive, Restricted) so employees know how carefully each type of sensitive information must be handled.

While reviewing server storage to free up space, an engineer found an old debug log file from CraveCart's payment processing service. It had been sitting untouched on a storage drive for months — a clear example of data at rest. The problem: the file was never supposed to exist in the first place, and it was written entirely in plaintext, with no cryptography applied at all.

Whenever a customer's payment failed, the payment service logged the entire transaction — including full card numbers and CVV codes — so engineers could "debug" the issue later. No one had ever encrypted this file or set it to automatically delete. If this file had been stolen, an attacker wouldn't need to break any encryption key at all; the confidentiality of every customer's payment information would already be gone, because there was no ciphertext protecting it.

A customer emailed CraveCart support with a strange complaint: they had tried to log in at "cravecart-secure-login.net" after clicking a link in a text message, and their browser flashed a security warning. CraveCart doesn't own that domain. The security team suspects an attacker built a lookalike checkout page to steal customer logins and payment details.

Every legitimate website that accepts payments uses asymmetric cryptography — a key pair made up of a public key anyone can use to start a secure connection, and a private key that only CraveCart's real server holds. A trusted Certificate Authority (CA) issues a digital certificate that proves a public key really belongs to CraveCart, and a valid digital signature on that certificate is what lets a browser confirm it's genuine — or warn the user when it isn't.

CraveCart is about to launch a new feature: letting restaurant partners upload their own menu photos directly. Before launch, the application security team requires a code review of the new feature as a standard step in CraveCart's Software Development Life Cycle (SDLC). The review is meant to catch secure coding mistakes before the feature ever reaches customers.

The findings were not good. The reviewer found multiple issues, ranging from missing input sanitization on user-submitted text to a forgotten software update that left the team without a working patch management process for a key library. Each of these findings represents a different point where the development team skipped a step that secure coding practices are supposed to catch.

CraveCart's audit log records every login to the admin dashboard, along with the account used, the time, and the location the login came from. This kind of continuous monitoring exists specifically to catch suspicious activity before it turns into a full-blown incident.

This morning, the on-call security analyst reviewing the overnight application log noticed something odd: an admin account that normally logs in during business hours from CraveCart's office network had logged in at 3:14 AM from an unfamiliar location, and moments later had exported a large batch of customer records. Individually, a late-night login or a data export might have an innocent explanation — but together, they're a strong indicator of attack, and a threat to the data integrity of CraveCart's systems if the exported records are altered or resold.

CraveCart's leadership has seen the case files above and called an emergency meeting. Six separate incidents in one unit — an injection attack, an access control failure, unencrypted payment data, a fake certificate, unsafe code shipped toward launch, and a middle-of-the-night data export — are more than bad luck. They're a pattern, and the executive team wants a plan.

No single security control fixes every problem CraveCart has faced. That's why security professionals rely on defense in depth: layering multiple controls so that if one fails, another is still standing between an attacker and CraveCart's assets. Every control still leaves some residual risk behind, and when the ideal control isn't possible right away, a compensating control can reduce risk in the meantime. Your job in this final case is to pull together everything you've learned across Cases 5A–5F into one prioritized plan.