Challenge 3: Web-Server-Layer Access Control vs. Application-Layer Checks — Solution Walkthrough

What web-server-layer access control actually does:

Per this chapter's own material, an IP restriction or Basic Auth
challenge configured directly on the web server rejects a
disallowed request before it ever reaches the application at all. The
application code behind that path never even runs for a rejected
request — the web server itself is the one making the decision and
sending back the rejection (typically a 401 or 403 status).

What relying on the application instead actually means:

If access control is left entirely to the application, every request
— including ones that will ultimately be denied — still has to reach
the application, get parsed, and run through whatever permission-check
logic the application contains, before that logic decides to reject
it. The web server itself does no filtering at all; it forwards
everything through indiscriminately.

Why the difference is meaningful:

Web-server-layer restriction is a more efficient first line of
defense — it can reject unwanted requests using cheap, simple rules
before any of the application's own, typically heavier code runs. It
also means the restriction doesn't depend on that particular
application's own code being correct — a bug in the application's own
permission-check logic can't accidentally let a request through if the
web server never forwarded it in the first place. Relying solely on
the application means every layer of defense depends on that one
piece of code getting it right, with the web server providing no
independent backstop.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the "rejected before reaching the
application at all" point from this chapter's own access-control
section is understood as a meaningful architectural difference —
fewer resources spent on rejected requests, and an independent layer
of defense that doesn't rely solely on the application's own logic
being bug-free.