Exercise 3: Why a WAF Still Matters After Fixing the Real SQLi Bug — Possible Solution
====================================================================

Per the chapter, a WAF is "a genuine defense-in-depth layer... not a
replacement for actually fixing the underlying application
vulnerability" -- which directly implies the reverse is also true:
fixing the underlying vulnerability doesn't make a WAF worthless
either. They operate at different layers and catch different kinds of
problems.

Reasons a WAF remains valuable even after the specific bug is fixed:

1. IT PROTECTS AGAINST THE NEXT BUG, NOT JUST THIS ONE. Fixing one
   specific SQL injection vulnerability addresses that one code path.
   A WAF filters malicious-looking HTTP request patterns generally, at
   the network edge, which can catch a DIFFERENT, not-yet-discovered
   injection vulnerability introduced later by a future code change --
   before it ever reaches the application at all.

2. IT BUYS TIME DURING A REAL VULNERABILITY WINDOW. If a new
   vulnerability is discovered (in this application's own code, or in
   a third-party dependency it uses) before a proper code fix can be
   written, tested, and deployed, a WAF rule can often be updated
   quickly to block the specific attack pattern in the meantime --
   a genuinely useful stopgap that a code fix, which takes real
   development and deployment time, can't provide as fast.

3. IT'S ONE LAYER IN A DEFENSE-IN-DEPTH STRATEGY, NOT A SINGLE POINT
   OF FAILURE. Per the chapter's own echo of `owasp1`'s theme, no
   single defense is assumed to be perfect on its own. If the code fix
   itself somehow has an edge case that wasn't fully tested, or a
   future regression accidentally reintroduces the vulnerability, the
   WAF is still there as an independent, second layer that doesn't
   depend on the application code being perfectly correct at every
   single point in time.

WHY THIS WORKS AS AN ANSWER
------------------------------
This treats "the real fix" and "the WAF" as addressing genuinely
different risks (the specific known bug vs. future/unknown bugs, plus
redundancy against human error) rather than treating the WAF as
merely a slower, worse version of the same fix -- directly reflecting
the chapter's own framing of the WAF as defense-in-depth alongside the
real fix, not competing with it.