Exercise 1: The Real Gap When Only the Button Is Hidden — Possible Solution ==================================================================== WHAT THE DEVELOPER ACTUALLY DID ------------------------------ They hid the "Delete Post" button in the dashboard's own interface from users without the right role - a purely visual/interface-level restriction - while leaving the actual delete action's own underlying code completely unprotected, with no current_user_can() check anywhere inside it. WHY THIS LEAVES A REAL, EXPLOITABLE GAP ------------------------------ Per this chapter's own warn-box, "hiding an 'Edit' link from the dashboard for a user without the right capability is a usability nicety, not a security boundary... A user who reaches the underlying action URL directly, bypassing the hidden button entirely, must still be blocked by the check itself." Hiding a button only prevents someone from discovering the action through the normal dashboard interface - it does absolutely nothing to prevent someone who already knows (or guesses, or finds documented) the underlying delete action's own URL or request format from triggering it directly, completely bypassing the dashboard's own UI entirely. WHY THIS IS A GENUINE, PRACTICAL RISK, NOT JUST A THEORETICAL ONE ------------------------------ WordPress admin actions typically follow predictable, well-documented URL patterns - someone with even modest technical knowledge (or access to publicly available documentation about how WordPress admin actions work) could construct the equivalent request directly, without ever needing to see or click the hidden button at all. Since the delete action's own code never actually verifies the requester's permission, it would carry out the deletion for absolutely anyone who sends a correctly-formed request - regardless of their actual role. WHAT THE FIX ACTUALLY IS ------------------------------ The delete action's own underlying code needs its own explicit current_user_can() check - for example, checking for the delete_others_posts or similar capability - performed independently of whatever the dashboard interface does or doesn't display. The UI-level hiding can remain as a genuine usability improvement, but it must never be treated as the actual security control. WHY THIS WORKS AS AN ANSWER ------------------------------ It restates this chapter's own explicit warning precisely, explains concretely how the gap could actually be exploited (bypassing the hidden button by reaching the action directly), and names the specific fix this chapter itself prescribes - an independent capability check inside the action itself.