Why Your Supabase Data Is Exposed (And You Don’t Know It)

The four RLS mistakes that silently leak production data — and how to verify your policies actually work.

In January 2025, security researchers found over 170 apps built with Lovable had exposed databases. Every user’s data — emails, messages, private records — was publicly readable by anyone with the project URL and the anonymous key. The anonymous key is embedded in every Supabase client-side app. It’s meant to be public.

The cause wasn’t a Supabase bug. It was missing Row Level Security.

If you’re building on Supabase, RLS is not optional. Any table without it is publicly readable and writable by anyone who can reach your API. This post covers the four RLS mistakes that silently expose data — including the one that’s counterintuitive — and how to verify your policies actually do what you think they do.

What RLS Actually Does

Row Level Security is a Postgres feature that lets you write SQL rules controlling which rows a user can see, insert, update, or delete. Supabase enforces these rules at the database level — below your application code, below your API routes, below your middleware.

Without RLS, the flow is:

Client (anon key) → Supabase API → PostgreSQL → All rows returned

With RLS:

Client (anon key) → Supabase API → PostgreSQL → Only rows matching the policy

The critical thing: RLS operates regardless of how the query arrives. If someone finds a way around your Next.js auth middleware and hits the Supabase API directly, RLS still enforces your rules. Application-level guards are a layer on top. RLS is the floor.

Mistake 1: RLS Disabled (The Data Leak)

Tables created through the SQL Editor or raw migrations have RLS disabled by default. The Supabase Dashboard shows a warning for tables missing RLS, but if you’re running migrations programmatically or using an ORM, you may never see it.

-- This table is publicly accessible to anyone with your anon key
CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users,
  email TEXT,
  subscription_status TEXT,
  private_notes TEXT
);
-- RLS is disabled. Anyone can SELECT * from this table.

The fix — enable RLS immediately after creating the table:

CREATE TABLE user_profiles (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID REFERENCES auth.users,
  email TEXT,
  subscription_status TEXT,
  private_notes TEXT
);

-- Enable RLS
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

-- Add a policy — users can only see their own profile
CREATE POLICY "Users can view own profile"
  ON user_profiles
  FOR SELECT
  TO authenticated
  USING (auth.uid() = user_id);

Check which tables in your project have RLS disabled:

SELECT schemaname, tablename, rowsecurity
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false;

Any table in that result set is publicly accessible.

Mistake 2: RLS Enabled With No Policies (The Silent Lockout)

This is the counterintuitive one. You enable RLS on a table but don’t add any policies. What happens?

Every query returns zero rows. No error. No warning.

This isn’t a bug — it’s by design. RLS with no policies defaults to deny all. The database is completely locked down. But because queries succeed (they just return nothing), this is easy to miss in development. You enable RLS, run a select, get an empty array, assume your policies are working.

const { data } = await supabase
  .from('user_profiles')
  .select('*');

console.log(data); // [] — but your table has 500 rows
// No error. You have no idea why.

The fix — always add at least one policy when enabling RLS:

-- Enable RLS
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

-- Users can read their own profile
CREATE POLICY "Users can view own profile"
  ON user_profiles
  FOR SELECT
  TO authenticated
  USING (auth.uid() = user_id);

-- Users can update their own profile
CREATE POLICY "Users can update own profile"
  ON user_profiles
  FOR UPDATE
  TO authenticated
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);

Note: FOR ALL creates one policy covering SELECT, INSERT, UPDATE, DELETE. Useful for simple cases, but you lose the ability to have different conditions for reads vs writes. Use separate policies when your read and write rules differ.

Mistake 3: service_role Key in Client Code

Your Supabase project has two keys:

anon key — public, safe for client-side use, RLS enforced
service_role key — private, bypasses RLS entirely, grants unrestricted database access

The service_role key is for server-side operations that legitimately need to bypass RLS — admin actions, background jobs, migrations. It should never appear in client-side code, environment variables accessible to the browser, or committed to git.

// Wrong — anyone who inspects your app can steal this key
// and read your entire database
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY // ← never public
);

// Right — anon key on the client
const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY // ← safe
);

If you need to run a privileged operation from the client — marking a payment complete, promoting a user role — put it in a Supabase Edge Function that validates the caller’s permissions before using the service_role key server-side:

// supabase/functions/promote-user/index.ts
import { createClient } from 'npm:@supabase/supabase-js';

Deno.serve(async (req) => {
  // Verify the caller is authenticated
  const authHeader = req.headers.get('Authorization');
  const userClient = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_ANON_KEY')!,
    { global: { headers: { Authorization: authHeader! } } }
  );

  const { data: { user } } = await userClient.auth.getUser();
  if (!user) return new Response('Unauthorized', { status: 401 });

  // Verify the caller is an admin (using RLS-enforced query)
  const { data: admin } = await userClient
    .from('admins')
    .select('id')
    .eq('user_id', user.id)
    .single();

  if (!admin) return new Response('Forbidden', { status: 403 });

  // Now use service_role to perform the privileged action
  const adminClient = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')! // Safe — server-side only
  );

  // ... perform admin action
});

Mistake 4: RLS Without Indexes (The Performance Trap)

This one doesn’t leak data — it kills query performance. RLS policies run on every row scanned by a query. If your policy references a column with no index, Postgres does a sequential scan of the entire table on every request.

-- This policy runs auth.uid() = user_id on every row
CREATE POLICY "Users see own data"
  ON posts
  FOR SELECT
  TO authenticated
  USING (auth.uid() = user_id);

Without an index on user_id, a table with 100,000 rows scans all 100,000 rows to find the ones that match. With an index, Postgres jumps directly to the matching rows.

-- Add this after creating the table and enabling RLS
CREATE INDEX idx_posts_user_id ON posts(user_id);

The performance difference on large tables can be 100x or more.

Second performance issue: calling auth.uid() without wrapping it in a subquery causes Postgres to re-evaluate it on every row:

-- Slower — auth.uid() called on every row
USING (auth.uid() = user_id)

-- Faster — auth.uid() evaluated once and cached
USING ((SELECT auth.uid()) = user_id)

The SELECT wrapper causes the query planner to evaluate auth.uid() once and reuse the result, rather than calling the function on every row.

How to Verify Your Policies Actually Work

The SQL Editor in Supabase runs queries as the postgres role, which bypasses RLS. Testing your policies in the SQL Editor tells you nothing about what your users can actually access.

Test from the client SDK:

// Test as authenticated user
const { data: { session } } = await supabase.auth.signInWithPassword({
  email: 'testuser@example.com',
  password: 'testpassword'
});

const { data, error } = await supabase
  .from('user_profiles')
  .select('*');

// Should only return the test user's own profile
console.log(data);

Or use the Supabase CLI to simulate different roles:

-- In the SQL Editor, test as anon role
SET LOCAL ROLE anon;
SELECT * FROM user_profiles; -- Should return 0 rows

-- Test as authenticated role with a specific user
SET LOCAL ROLE authenticated;
SET LOCAL request.jwt.claims TO '{"sub": "your-user-uuid"}';
SELECT * FROM user_profiles; -- Should return only that user's rows

The Production Security Checklist

Before you ship:

[ ] RLS enabled on every table in the public schema
[ ] Every RLS-enabled table has at least one policy
[ ] service_role key is not in any client-side code or public environment variable
[ ] Indexes added on every column referenced in RLS policies
[ ] auth.uid() wrapped in (SELECT auth.uid()) in policies
[ ] Views have security_invoker = true if they should respect RLS
[ ] Policies tested from the client SDK, not the SQL Editor
[ ] Storage buckets have RLS policies configured (separate from table policies)

Run this query to find all public tables missing RLS:

SELECT schemaname, tablename
FROM pg_tables
WHERE schemaname = 'public'
  AND rowsecurity = false
ORDER BY tablename;

If that query returns anything, your data is publicly accessible. Fix it before you ship.

If you’re building on Supabase and hitting an RLS edge case — multi-tenant isolation, role-based access control, storage bucket policies, realtime subscription filtering — drop a comment. I’ll answer.

Disclosure: This post was produced by AXIOM, an agentic developer advocacy workflow powered by Anthropic’s Claude, operated by Jordan Sterchele. Human-reviewed before publication.

推荐订阅源

DEV Community