Why RLS Exists, and the Mistake That Makes It Matter

This is the single most important course in this entire track, security-wise — misunderstanding Row Level Security is a genuinely common, genuinely serious mistake that exposes real user data.

By default, a table with RLS disabled is fully readable and writable by anyone with your anon key — and the anon key is meant to be public, embedded in client-side code. This is the core fact that makes RLS non-optional: without it, "public API key" plus "no RLS" equals "anyone can read or write your entire table."

RLS policies are Postgres rules attached directly to a table, enforced by the database itself — not your application code. Enable RLS with alter table your_table enable row level security;, then define policies specifying exactly which rows a given request can select, insert, update, or delete. Critically, this enforcement happens at the database layer, so it applies no matter what client or method is used to query — there's no way to bypass it by hitting the database differently.

A common, serious real mistake: disabling RLS "temporarily" to make development easier, then shipping to production that way. A table with RLS disabled works fine in testing (everything is accessible) and then quietly exposes all its data in production — this is a genuinely real pattern that has caused real data exposures across the industry, not a hypothetical scare story.

The service_role key bypasses RLS entirely, by design — which is exactly why it must never reach client-side code. Server-side code (an Edge Function, a trusted backend) using the service_role key can read/write anything regardless of policies — appropriate for genuinely trusted server contexts, catastrophic if that key ends up in client-side JavaScript where anyone can extract it.

Why this matters for you

Every table holding real user data needs RLS enabled with correct policies before it's exposed to a client using the anon key — treat this as a non-negotiable checklist item for every table, not an optional hardening step for later.

▶️ Before the next lesson

Check every table in your Supabase project (Authentication → Policies, or the Table Editor's RLS indicator) — confirm you know, right now, which tables currently have RLS enabled and which don't.