Security Beyond RLS

Layers of defence

Keep the service role or secret key only in server environments and rotate it if it leaks. Review Auth settings: email confirmation, password strength, OTP expiry, redirect allow list, and CAPTCHA on sign-up to slow bots. Auth endpoints have built-in rate limits you can tune. Expose only schemas you intend through the API, never put sensitive tables in an exposed schema without RLS, and enable MFA for dashboard accounts. The dashboard's Security Advisor flags issues such as tables without RLS; run it before launch.

Secure, fast and portable

Production readiness means locking down keys and auth, tuning Postgres and planning for backups, cost and exit.

Quick security checks

SQL you can run as a privileged role.

-- policies per table: tables with RLS on but zero policies deny everything
select schemaname, tablename, count(*) as policies
from pg_policies
group by schemaname, tablename
order by policies;

-- functions that run as their owner and deserve review
select n.nspname, p.proname
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where p.prosecdef and n.nspname = 'public';

Scan your front-end bundle for secrets

Search the built JavaScript for the service key prefix or secret-key value before deploying; a leaked privileged key gives full database access.

त्वरित जाँच: What should you do if the service_role key is committed to a public repo?

• Make the repository private and do nothing else
• Enable RLS and keep using it
• Rename the environment variable
• Rotate it immediately and remove it from the code