Dangerous admin actions, deleting a record, refunding a payment, banning a user, usually get a confirmation dialog: "are you sure you want to do this?" That's good interface design, meant to prevent accidental clicks. It's worth checking, separately, whether that dialog is the only thing standing between a request and the action actually happening.
The question underneath the confirmation dialog
A confirmation dialog is a UI-layer safeguard against accidental clicks by someone who's already allowed to perform the action. It was never designed to answer a completely different question: is the person making this request actually allowed to perform it at all. Those are separate checks, built by different parts of the app, and it's entirely possible for a dialog to exist without a matching server-side permission check standing behind it.
How to actually test this
Find a dangerous admin action in your app, open your browser's dev tools, and watch the network request that fires the moment you click confirm on the dialog. Then try firing that exact same request directly, using a tool like curl or Postman, from an account that isn't supposed to have permission to perform it, skipping the dialog and the admin interface entirely. If the action still goes through, the dialog was the only thing between a request and the action happening, and it's not a security control at all, it's a courtesy for people already allowed to click it.
Why this specific gap is easy to introduce
Building the confirmation flow, the button, the dialog, the "are you sure" copy, is a natural, visible part of building the feature, and it's what gets tested by clicking through the interface normally. Adding a separate, explicit server-side check confirming the requester's actual permission is a less visible step that doesn't change what a normal admin sees when they use the feature correctly. It's easy to build the visible part carefully and skip the invisible part, because skipping it produces no symptom at all during ordinary testing.
What actually needs to be true
- Every dangerous action needs its own server-side check confirming the requester's specific permission, independent of whatever confirmation step the interface shows.
- That check needs to happen on the actual request that performs the action, not just on the page that displays the button leading to it.
- Test this directly, by trying to fire the underlying request from an account that shouldn't have access, rather than assuming the dialog implies a check exists behind it.
A confirmation dialog is a good, worthwhile piece of interface design. It answers "did you mean to click this," not "are you allowed to." Conflating the two is an easy mistake to make, because from inside the app, using it correctly, they look identical. They're only different the moment someone skips the interface entirely and talks to the server directly, which is exactly the scenario worth testing for on purpose.