Row Level Security disabled

What the finding looks like

How to fix it

This is real generator output, not a template — a scan substitutes your schema, table and inferred ownership column.

-- Generated by RowShield. Review before running in production.
ALTER TABLE public.invoices ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.invoices FORCE ROW LEVEL SECURITY;

CREATE POLICY invoices_select_own
  ON public.invoices
  FOR SELECT
  TO authenticated
  USING (user_id = (SELECT auth.uid()));

CREATE POLICY invoices_insert_own
  ON public.invoices
  FOR INSERT
  TO authenticated
  WITH CHECK (user_id = (SELECT auth.uid()));

CREATE POLICY invoices_update_own
  ON public.invoices
  FOR UPDATE
  TO authenticated
  USING (user_id = (SELECT auth.uid()))
  WITH CHECK (user_id = (SELECT auth.uid()));

CREATE POLICY invoices_delete_own
  ON public.invoices
  FOR DELETE
  TO authenticated
  USING (user_id = (SELECT auth.uid()));

Related guides

• RLS disabled on a public table: the most common Supabase leak
• The migration that added a table and forgot RLS
• The Supabase security gaps Lovable apps ship with
• Cursor-written migrations and the RLS line that never appeared
• Claude Code + Supabase MCP: fast schema, slow policy
• The migration that recreated the table without its policies
• Prevent Supabase RLS bypass
• Check whether your Lovable app is leaking data
• Bolt.new shipped tables without RLS
• Detect Supabase schema drift after migrations
• What the Supabase Security Advisor does not do
• Continuous RLS monitoring for Supabase

What people search for