Supabase 테이블에 RLS가 꺼져 있어요

이게 무슨 말이냐 (쉽게)

Supabase는 기본적으로 API 주소만 알면 테이블에 접근할 수 있게 열려 있어요. 그 문을 잠그는 게 RLS(Row Level Security, 행 단위 보안)입니다. RLS를 켜고 "본인 데이터만 볼 수 있다"는 규칙(정책)을 만들어야, 비로소 남의 데이터가 가려져요.

RLS를 안 켜면? 앱 화면에는 내 정보만 보이지만, 브라우저 개발자도구나 간단한 요청 한 줄이면 전체 회원 테이블이 통째로 나옵니다. 화면에서 안 보이는 것과, 서버가 안 주는 것은 완전히 다른 얘기예요.

실제로 어떻게 터지나 (시나리오)

당신이 만든 SaaS에 회원 1,000명이 가입했어요. profiles 테이블에 이메일·이름·결제 잔액이 들어있죠. RLS는 안 켰고요.

누군가 당신 사이트를 브라우저에서 열고 → 개발자도구 Network 탭을 봅니다 → Supabase 주소와 anon key(앱에 그대로 박혀 있음)를 복사 → 터미널에서 그 주소로 select * 한 번. 끝. 1,000명 전체 이메일·잔액이 JSON으로 쏟아집니다. 해킹 도구도, 비밀번호도 필요 없어요. anon key는 원래 공개되는 키라서, 잠금은 오로지 RLS뿐이거든요.

최악의 경우

• ·회원 전체 개인정보(이메일·전화·주소) 유출 → 개인정보보호법 위반 신고/과징금 대상.
• ·update·delete도 막혀있지 않으면, 남이 내 회원들의 잔액·등급을 바꾸거나 데이터를 지울 수도 있어요.
• ·실제 사례: 바이브코딩으로 만든 앱 Moltbook은 출시 3일 만에 RLS 미설정으로 API 키 150만 개·이메일 3.5만 건이 유출됐습니다(Wiz Research). CVE-2025-48757은 Lovable로 만든 앱 170개+에서 같은 RLS 누락이 확인됐고요. 바이브코더에게 가장 흔하고 가장 치명적인 구멍입니다.

나한테 해당되나? (체크)

• ·Supabase(또는 Postgres)를 백엔드로 쓴다.
• ·회원·주문·게시글 등 사용자 데이터를 담는 테이블이 있다.
• ·enable row level security를 명시적으로 켠 기억이 없다.
• ·테이블을 Supabase 대시보드나 AI가 만들어준 SQL로 그냥 생성했다.

→ 2개 이상 체크되면 거의 확실히 해당됩니다. 아래대로 고치세요.

어떻게 고치나 (복붙)

각 테이블마다 ① RLS를 켜고 ② "본인 것만" 정책을 추가합니다. Supabase SQL Editor에 붙여넣고 테이블명만 바꾸세요.

-- 1) 잠금장치 켜기 (테이블마다)
alter table public.profiles enable row level security;

-- 2) 읽기: 본인 행만
create policy "본인 프로필만 조회"
on public.profiles for select
using ( auth.uid() = id );

-- 3) 수정: 본인 행만
create policy "본인 프로필만 수정"
on public.profiles for update
using ( auth.uid() = id );

-- 4) 입력: 본인 id로만
create policy "본인 프로필만 생성"
on public.profiles for insert
with check ( auth.uid() = id );

고친 뒤 확인

1. 01

   대시보드에서 잠금 표시 보기

   Supabase 대시보드 → Table editor에서 테이블에 RLS enabled 표시가 켜져 있는지 확인.

2. 02

   로그아웃 상태로 불러보기

   anon key로 select * from profiles 호출 → 빈 결과(또는 거부)가 나와야 정상.

3. 03

   로그인 상태로 불러보기

   로그인 사용자로는 본인 행만 나오는지 확인.

규제 연결

이 한 건이 곧 개인정보보호법(PIPA) 안전조치 의무 위반이에요. 관련 조항은 ISMS-P 2.6(접근통제)·PIPA 제29조(안전조치의무)입니다. 다만 리포트가 조항을 자동으로 붙여 주지는 않습니다 — 신뢰 센터의 참고 대조표에서 직접 보실 수 있습니다.