Bolt.new + Supabase Auth Hardening
Updated 2026-10-17
Authentication is not authorization. A working login screen tells you nothing about whether user A can read user B's data.
Auth configuration
Restrict Site URL and redirect URLs to your production and preview domains, enable email confirmation if identity matters, and disable providers you do not use.
Authorization in the database
Every query from the client should be constrained by RLS using auth.uid(). Do not rely on filtering by user id in frontend code — attackers remove the filter.
Checklist
- Redirect URL allowlist
- Unused providers disabled
- RLS uses auth.uid()
- No admin checks only in the UI
- Second test user can't see first user's data
Copy-paste fix prompt
Review my Bolt.new app's Supabase auth: list redirect URLs and providers in use, find any client-side-only authorization checks (e.g. hiding admin buttons), and replace them with RLS policies or server-side checks.FAQ
Is hiding an admin page in the UI enough?
No. Anyone can call the API directly. Enforce roles in RLS policies or server code.
Should I store roles in user metadata?
User-editable metadata must not be trusted for authorization. Use a roles table protected by RLS or app_metadata set server-side.
Check your deployed app in ~25 seconds
Free passive scan: leaked keys, Supabase exposure, public config files and headers.
Run a free scan