How do I test admin permissions?

Why UI-hiding isn't enough

Hiding an "Admin" menu item for regular users stops them clicking it, but it doesn't stop them reaching the same page by typing the URL, or calling the same database/edge function request directly. Real protection has to live in row-level security (RLS) policies and server-side checks, using a separate user_roles table — never a role column on the user's own profile row.

How to test properly

1. Create a genuine non-admin test account.
2. Try navigating directly to admin routes (e.g. /admin, /dashboard/users) while logged in as that account — confirm you're blocked or redirected, not just that the nav link is hidden.
3. Try triggering admin-only actions the account shouldn't have — deleting another user, changing a role, viewing another user's private data — and confirm they fail server-side.
4. Check what happens logged out entirely for the same routes and actions.
5. Confirm a user cannot self-assign a role — e.g. by checking that role changes require an existing admin and go through server-side validation.

A prompt to verify this

Confirm that admin-only actions and routes are protected by a server-side check against the user_roles table, not just hidden in the UI. Show me where that check happens for each admin action.

What usually goes wrong

• Role checks written only in front-end React code (if (user.role === 'admin')), which can be bypassed since the actual data request isn't restricted.
• Roles stored as a column on the profiles/users table instead of a separate user_roles table — this is a known Lovable/Supabase RLS pitfall because a user can sometimes edit their own profile row.
• Forgetting to test cross-account access — user A reading or editing user B's private data.

See also /questions/how-do-i-test-rls, the underlying mechanism that should be enforcing all of this.