Supabase Row Level Security(RLS): 테이블을 확실하게 잠그기

Supabase SQL 편집기에서 이 쿼리를 실행해, 노출된 public 스키마에서 아직 RLS가 꺼져 있는 모든 테이블을 나열하세요. 대시보드의 Security Advisor도 같은 문제를 “RLS disabled in public”으로 보고합니다.

select tablename
from pg_tables
where schemaname = 'public'
  and rowsecurity = false;

각 테이블에서 RLS를 켜고, 작업마다 정책을 하나씩 추가하세요. 정책 대상을 authenticated 역할로 한정하고, 행의 소유자 컬럼을 auth.uid()와 비교하세요. INSERT와 UPDATE에는 with check가 필요합니다. 그래야 사용자가 다른 사람 소유의 행을 쓸 수 없습니다.

alter table public.profiles enable row level security;

create policy "Users read own profile"
  on public.profiles for select
  to authenticated
  using ((select auth.uid()) = user_id);

create policy "Users update own profile"
  on public.profiles for update
  to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

using (true) 같은 임시 정책을 실제 조건으로 바꾸세요. 사용자가 직접 수정할 수 있는 user_metadata를 권한 판단의 근거로 삼지 말고, 대신 app_metadata나 역할 테이블을 사용하세요. 뷰는 security_invoker = true로 생성하지 않으면 RLS를 우회하며, 스토리지 버킷에는 storage.objects에 대한 별도 정책이 필요합니다.

공격자와 똑같은 방식으로 API를 조회하세요. 즉, 공개 키만 사용하고 사용자 세션은 없이요. 공개되면 안 되는 행이 반환된다면 정책이 너무 열려 있는 것입니다.

curl "https://<project>.supabase.co/rest/v1/profiles?select=*" \
  -H "apikey: <anon-key>" \
  -H "Authorization: Bearer <anon-key>"

service_role(sb_secret_) key는 API route나 Edge Functions 같은 서버 코드에서만 사용하고, 절대 NEXT_PUBLIC_이나 VITE_ 접두사 뒤에 두지 마세요. 한 번이라도 브라우저로 전달된 적이 있다면 대시보드에서 교체하세요.