Every lesson in this course has taught one control in isolation. Production systems fail differently: a real breach is rarely one dramatic flaw, it is several individually survivable weaknesses stacked together — a missing object-level authorization check, combined with no rate limiting to slow down whoever finds it, combined with logging too thin to reconstruct what happened once someone does. This capstone puts those pieces back together. You will stand up a small, deliberately weak API on your own machine, one you own end to end, and hardening pass by hardening pass, close the gaps this course covered, verifying each stage against explicit acceptance criteria before moving to the next.
This is framed entirely as defending a system you own. The starter application in this lesson runs locally, on your own machine, against no real user data and no real network exposure — you are the operator hardening your own infrastructure, not probing anyone else's. Nothing in this lesson describes attacking a system you do not control, and the same discipline applies beyond this exercise: the techniques here are for securing systems you are responsible for, never for testing access against a system without explicit authorization to do so.
Analogy🏏Cricket
🏏 Think of it like cricket: A curator handed responsibility for a new international venue does not certify the ground fit for a marquee match by inspecting the outfield once and declaring it done. The certification runs in stages, each with its own defined pass criteria checked before the next stage even starts — pitch composition and bounce consistency verified first, then drainage tested under simulated heavy rain, then boundary rope tension and advertising-board stability checked under simulated crowd conditions, then floodlight coverage measured across every part of the square specifically because a gap missed at the pitch stage can undermine a control that looks fine at the drainage stage. A curator who skipped straight to floodlight testing without first confirming the pitch itself was sound would be validating something built on an unverified foundation. Just as ground certification runs as a defined sequence of stages, each verified before the next begins, hardening this capstone's API runs as a defined sequence of stages, each verified against explicit acceptance criteria before the next begins. Just as the curator owns this specific ground and is certifying it for the matches it will actually host, you own this specific API and are hardening it end to end, not testing access against a ground that belongs to someone else. The insight is that a system's overall soundness is the product of every stage actually passing its own specific check, not of a single, final look that assumes everything underneath it was already fine.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.