advancedScenario Questions

Scenario 8: An admin panel's 'Delete User' button is hidden in the UI for non-admin users, but a curious user opens dev tools and successfully calls the DELETE endpoint directly. What went wrong, and what's the fix?

The authorization check existed only in the FRONTEND (a hidden button), with no corresponding server-side enforcement — the backend endpoint itself trusted the caller. The fix is to enforce the check on the server, using either a requestMatchers rule restricting the endpoint's HTTP method/path to a required role, and/or a @PreAuthorize annotation directly on the underlying service method, so the rule holds regardless of what UI (or curl command) calls it.

This is a Pro chapter

Sign in, then upgrade to Pro or Power to unlock this and the full Spring Ecosystem Mastery library.

Scenario 8: An admin panel's 'Delete User' button is hidden in the UI for non-admin users, but a curious user opens dev tools and successfully calls the DELETE endpoint directly. What went wrong, and what's the fix?

Next Step

Continue to Scenario 9: Right after deployment, every newly registered user can never log in, even immediately after signing up with the exact password they chose.← Back to all Spring Security questions