Exercise 3: Least Privilege as Defense in Depth — Possible Solution
====================================================================

Least-privilege account design is defense in depth because it operates
at a COMPLETELY DIFFERENT LAYER than parameterized queries — it does
nothing to stop an injection attempt from happening, but it directly
limits what a successful one can achieve, if the application-layer
defense ever fails.

Parameterized queries (SQLi course, Chapter 7) prevent untrusted input
from ever being interpreted as SQL syntax in the first place — that's
the primary, correct fix, and it works by stopping the attack at its
actual root cause (data being treated as code). Least privilege doesn't
touch that mechanism at all; it operates purely on WHAT THE DATABASE
ACCOUNT ITSELF is allowed to do, regardless of how a query reached it.

WHAT IT SPECIFICALLY LIMITS: if, despite parameterized queries, some
other code path (a raw query left unparameterized by mistake, a new
developer unaware of the convention, a third-party library with its
own vulnerability) allowed an injection to succeed anyway, the
resulting damage is bounded by the compromised account's actual
grants. A properly scoped account — say, one limited to SELECT/INSERT/
UPDATE/DELETE on its own application's tables only — means even a
successful injection can't read other databases on the same server,
can't drop tables it was never granted DROP on, and can't create new
accounts to persist access.

WHAT IT DOES NOT PREVENT: least privilege does nothing to stop the
injection from happening, and does nothing to protect the data the
account WAS legitimately granted access to — if the application's own
tables contain sensitive data and the account has SELECT on them, a
successful injection can still read that data. It narrows the blast
radius; it does not close the hole. Both layers are needed together —
this is exactly what "defense in depth" means: multiple independent
layers, so that one layer failing doesn't mean total compromise.