How to Guard a Destructive Action With a Typed Confirmation

• [ ] An action that is genuinely destructive and hard or impossible to reverse.
• [ ] A role or permission model that can distinguish a privileged operator (for example a super admin) from ordinary users.
• [ ] Server-side authorization (never rely on hiding the button in the UI alone).
• [ ] The exact name/identifier of the thing being deleted, available to show the user.

1. 1

   Gate the action

   Restrict the action to the smallest role that needs it. Gate the delete to super admins only, and enforce it on the server, not just by hiding the control. Hiding the button is UX; the server check is the actual guarantee.

2. 2

   Lock related surfaces

   Lock the related high-risk surfaces to the same role. If editing the same object is also dangerous, lock the edit page to super admins too, so a lower-privileged account can't reach a destructive path a different way.

3. 3

   Require typed confirmation

   Require the user to type to confirm — not just click. A modal with an "OK" button is one misclick away from disaster. Require the user to type the object's exact name (or the word DELETE) and only enable the confirm button on an exact match:

4. 4

   Re-check on the server

   Re-check the role on the server when the action fires. The confirmation gate is client-side; the authorization must be re-verified in the handler that actually performs the delete. Two independent gates means both a role check and a deliberate confirmation must pass.

5. 5

   Name the scope

   Make the confirmation unambiguous about scope. Name exactly what will be deleted and what won't survive, so the person typing the name knows precisely what they're ending.

6. 6

   Test both paths

   Test both the allow and the deny path. Log in as a super admin and confirm delete works after typing the name; log in as an ordinary admin and confirm the action is blocked on the server, not merely hidden.

   if (!currentUser.isSuperAdmin) {
     return forbidden("Only super admins can delete this.");
   }

   <input value={typed} onChange={e => setTyped(e.target.value)}
          placeholder={`Type "${name}" to confirm`} />
   <button disabled={typed !== name} onClick={onDelete}>Delete</button>

Match the confirmation phrase to the risk: typing the object's real name proves the user knows exactly what they're deleting, which a generic "DELETE" doesn't.

• A super admin can delete only after typing the exact name; a wrong or empty value keeps the button disabled.
• An ordinary admin is blocked by the server, and confirmed blocked even if the button is forced visible.
• Editing the same object is restricted to super admins.
• The confirmation dialog names exactly what is being removed.

• [ ] Destructive action gated to the minimum role, enforced server-side.
• [ ] Typed-name confirmation required, exact-match only.
• [ ] Authorization re-checked in the execution handler, not just the UI.
• [ ] Related dangerous surfaces (edit) locked to the same role.
• [ ] Both allow and deny paths tested with different roles.
• [ ] Confirmation copy names the exact scope of what's deleted.

• Keeping the same editor component across the builder and edit pages avoids behavioral drift — one component, one behavior, fewer surprises around the dangerous surface.
• For the highest-stakes deletes, add a soft-delete/undo window or an audit-log entry so even a confirmed action is recoverable or at least attributable.