Exercise 3: A 403's Two Possible Sources — Possible Solution
====================================================================

WHY A 403 DOESN'T TELL YOU WHO PRODUCED IT
------------------------------
Per this chapter's warn-box, "an authorization failure and a security
block can look identical from the client side. The application itself
might be correctly enforcing a permissions rule, or a Web Application
Firewall (WAF)... might be rejecting the request based on its IP,
pattern, or rate before it ever reaches the actual application." Both
situations produce the exact same 403 status code visible to the
client, with no built-in way to distinguish "the app said no" from "a
security layer in front of the app said no" from the response alone.

WHAT WOULD ACTUALLY BE NEEDED TO TELL THEM APART
------------------------------
Per this chapter, "telling the two apart from outside usually needs
the same thing Chapter 7 needed for a plain network-layer firewall:
server-side or WAF logs, not just the client's own response." Someone
with access to the application's own logs or the WAF's logs would need
to check whether the request actually reached the application at all.

THE CHAPTER 7 CONNECTION
------------------------------
This chapter explicitly describes a WAF as "itself a specialized,
application-aware relative of Chapter 7's own firewalls." The same
core problem from Chapter 7 - a block that's invisible from the
client's side, requiring someone with visibility into the blocking
layer's own logs to confirm it - reappears here at the application
layer instead of the network layer, just with a WAF playing the role
Chapter 7's network firewall played.

WHY THIS WORKS AS AN ANSWER
------------------------------
It names both candidate sources of the 403 accurately, explains why
the client-side response can't distinguish them, and correctly
identifies the parallel this chapter draws to Chapter 7's own
firewall-visibility problem rather than treating the two chapters as
unrelated.