A team ships an API gateway and a WAF, checks the security review's boxes for 'rate limiting' and 'input filtering,' and moves on — then six months later a BOLA vulnerability (Lesson 9) lets one customer read another customer's order history through a perfectly well-formed, perfectly rate-limited request. Nothing about that request looked like an attack to the gateway or the WAF, because neither tool was ever positioned to catch it. This lesson exists to draw that line precisely: gateways and WAFs are real, valuable controls for a specific, bounded class of problems, and treating them as a general security solution is how teams end up believing they're protected when the actual gaps — authorization logic, business logic, anything that requires understanding what a request means rather than what it looks like — are sitting untouched underneath.
Overstating what these tools do is not a harmless simplification; it is how organizations end up genuinely unprotected while believing the opposite. A WAF vendor's marketing and a security review's checklist both have an incentive to describe coverage in the broadest possible terms, and the gap between that description and what the tool actually inspects is exactly where the next incident tends to live.
Analogy🏏Cricket
🏏 Think of it like cricket: A stadium's metal detectors at the spectator gates are excellent at what they actually check — is this person carrying a prohibited physical object — and they catch that reliably, every time, for every person who walks through. What they cannot tell you is whether the person who just passed through, carrying nothing prohibited, is actually who their ticket says they are, or whether they're sitting in a seat block they're not entitled to once they're inside. A ground that treated 'everyone passed the metal detector' as equivalent to 'everyone inside is exactly where they're supposed to be' would be badly misreading what the detector was ever built to verify. Just as a metal detector checks for prohibited objects and says nothing about whether someone belongs in a specific seat, a WAF checks request patterns against known attack signatures and says nothing about whether an authenticated, well-formed request is actually authorized for the specific resource it's requesting. Just as ticket verification and seat-block enforcement need a separate, purpose-built check beyond the gate scanner, authorization logic needs its own enforcement inside the application, beyond whatever the gateway or WAF inspected on the way in. The insight is that a control built to catch one specific shape of problem provides zero coverage for a different shape of problem, no matter how well it does its actual job.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.