SecureStartKit
SecurityFeaturesPricingDocsBlogChangelog
Sign inBuy Now
Home/Glossary/Row Level Security
Data Layer

Row Level Security(RLS)

Also known as: RLS, row-level security

Definition

Row Level Security is a Postgres feature that filters which rows of a table each user can see or modify. In Supabase apps, RLS policies are written in SQL and evaluated on every query against the authenticated user's JWT claims, making the database itself the authorization boundary.

What is Row Level Security?

Row Level Security is enforced by Postgres on every SELECT, INSERT, UPDATE, and DELETE against a table where RLS is enabled. Policies are SQL expressions that return true or false for each row given the current session's claims.

In a Supabase + Next.js app, the session is the user's JWT, and the canonical claim is auth.uid(). A typical "users only see their own rows" policy reads using (auth.uid() = user_id). Without that policy, the table denies all access to authenticated users by default once RLS is enabled.

How does RLS work with the anon key vs service_role?

The anon key respects RLS; the service_role key bypasses it. That asymmetry is the architectural point: the anon key is safe to ship to the browser because RLS gates every query, while service_role belongs only on the server.

When should you enable RLS?

On every table that holds user data. The recommended posture is enable-and-deny-all: turn RLS on, write no policies, then add policies one at a time as needs surface. A missing policy fails closed (denies access) rather than failing open (allowing access).

Learn more

  • Supabase RLS Policies That Actually Work
  • Free RLS Policy Generator

Related terms

  • Backend-only data accessBackend-only data access is an architectural pattern where the database is never queried directly from the browser. All queries run through Server Actions or Route Handlers using the service_role key, after server-side authentication and Zod validation. The browser only receives data the server explicitly returns.
  • Service role keyThe service role key is the Supabase API key that bypasses Row Level Security and grants full database access. It must never enter the browser bundle. In a Next.js app, the service role key is used only in Server Actions and Route Handlers via createAdminClient, with the import gated by Next.js's server-only enforcement.
  • Anon keyThe anon key is the Supabase public API key that respects Row Level Security. It is safe to include in the browser bundle because RLS gates every query against the user's JWT claims. The anon key alone cannot read or modify rows unless an RLS policy explicitly allows it.
  • JWTA JWT is a signed, base64url-encoded token carrying claims about a user. Supabase issues JWTs after authentication, signs them with ES256 asymmetric keys (default for new projects since October 2025), and Next.js apps validate them server-side via getClaims without a network round trip to the auth server.
← Back to full glossary