Authorize a Server Action at the Operation, Not Just at the Button

Example: an identifier is changed manually

A user allowed to edit their own draft may try another article's identifier. The operation should reject the unauthorized target without changing it. Test using disposable accounts and inspect the resulting state, rather than assuming the absence of a visible edit link prevents a direct request.

Verify legitimate work still succeeds

Exercise authorized, unauthorized and expired-session requests. Keep errors useful without disclosing sensitive record details. Security and usability are complementary here: the authorized user should understand a failed action while an unauthorized request should not gain broader access through retries or alternate UI paths.

Can I trust an action because only my frontend knows its name?

No. Treat the server operation as a boundary that needs its own permission and input checks. The interface can guide legitimate users, but it should not be the only thing preventing an unauthorized account from requesting a sensitive change.

Primary reference and editorial note

Primary reference: nextjs.org

Prepared October 19, 2026 with AI-assisted drafting and source review. Scenarios are illustrative; this guide does not claim hands-on product testing or measured results. Platform behavior can change; consult the linked current documentation before implementing changes.