Cursor가 테이블을 열어 Supabase RLS 오류를 수정하는 원리

요약 (TL;DR)

• Supabase에서 'new row violates row-level security policy' 오류로 삽입(insert)이 실패할 때, AI 에디터들은 보통 using (true) 또는 with check (true) 정책을 사용하거나 RLS를 비활성화하여 이를 '수정'합니다.
• 이렇게 하면 오류가 사라지는데, 이는 테이블을 anon 키를 가진 누구에게나 읽기 가능(readable)하거나 쓰기 가능(writable)하게 만들기 때문입니다. 이 anon 키는 프런트엔드 번들에 포함됩니다.
• 진짜 해결책은 auth.uid()를 기반으로 하는 네 가지 소유자 범위 정책(owner-scoped policies)과, anon 키를 사용한 60초 동안의 curl 테스트가 필요합니다.

지난주에 작은 메모 앱에서 이런 일을 겪었습니다. 브라우저에서 삽입을 시도하자 new row violates row-level security policy for table "notes" 오류가 발생했습니다. 이 오류 메시지를 Cursor에 붙여넣고 수정해 달라고 요청했습니다.

실제로 수정되었습니다. 오류는 사라졌고, 앱은 작동했으며, 저는 거의 만족하고 넘어가려 했습니다. 그러다 그 코드가 작성한 마이그레이션(migration)을 읽어보게 되었습니다.

'수정'된 내용은 누구든, 로그인했든 안 했든, 테이블의 모든 행을 읽고 쓸 수 있게 하는 정책이었습니다. 아무것도 검사되지 않기 때문에 앱은 작동했던 것입니다.

취약한 코드 (The Vulnerable Code)

AI 에디터가 RLS 오류를 수정하기 위해 일반적으로 작성하는 코드는 항상 참(always-true)인 정책을 만들거나, 아예 RLS를 끄는 것입니다. 둘 다 접근 제어(access control)를 제거함으로써 오류를 무마시킵니다.

-- 삽입 오류를 '수정'하기 위해 AI가 작성한 코드 (CWE-863, 잘못된 권한 부여)
create policy "Enable insert for all users"
on public.notes for insert
...

이것이 왜 중요한지 설명합니다. Supabase의 anon(publishable) 키는 공개되어야 하는 것이 목적입니다. 이 키는 JavaScript 번들에 위치하며, 누구나 devtools에서 복사할 수 있습니다. Row Level Security가 바로 그 키와 데이터 사이를 막아주는 유일한 장벽입니다. using (true) 정책은 Postgres에게 모든 행을 통과시키라고 지시합니다. RLS가 비활성화되면, 테이블에 권한(grant)이 있는 어떤 역할이라도 자동 생성된 REST API를 통해 모든 내용을 읽고 쓸 수 있게 됩니다.

두 번째로 많이 보이는 "수정"은 더 심각합니다. 정책 라우팅(policy route)이 혼란스러워지면, AI는 service_role 키를 사용하는 클라이언트로 삽입을 이동시키고 이를 NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY로 노출시킵니다. Supabase 자체 문서에 따르면 이 키는 bypassrls 속성을 가진 service_role 역할(role)을 통해 작동합니다. 공개 환경 변수(public env var)에 존재한다는 것은 전체 데이터베이스가 브라우저에서 읽을 수 있다는 의미입니다.

이런 일이 계속 발생하는 이유

AI 에디터들은 오류를 제거하는 데 최적화되어 있으며, 항상 참(always-true)인 정책이 가장 짧은 차이점(diff)으로 이를 달성합니다. 모델은 "행 수준 보안 정책 위반(violates row-level security policy)"을 보고 패턴 매칭하여 "정책이 너무 엄격하다"고 판단하고 이를 완화시킵니다.

또한 학습 데이터에는 using (true)가 많이 사용됩니다. 퀵스타트(Quickstarts)나 튜토리얼에서는 공개 조회 테이블에 이 구문을 사용하며, "모든 사용자에게 읽기 액세스 활성화(Enable read access for all users)"와 같은 정책 이름이 끊임없이 등장합니다. 국가 코드 테이블의 경우 이는 괜찮습니다. 하지만 사용자 메모, 송장 또는 채팅 메시지 테이블의 경우에는 데이터 유출입니다.

이는 가설이 아닙니다. 2025년 5월 29일에 발표된 CVE-2025-48757은 Lovable이 생성한 앱에서 원격 인증되지 않은 공격자가 데이터베이스 테이블을 읽거나 쓸 수 있게 하는 불충분한 RLS 정책을 설명합니다. 이 문제를 보고한 Matt Palmer는 자신의 글에서 노출된 이름, 이메일, 타사 API 키 및 결제 상태 데이터를 나열했습니다. Lovable은 각 고객이 자체 앱의 데이터를 보호할 책임이 있다고 주장하며 CVE를 부인하고 있습니다. 이 논쟁 자체가 핵심입니다. 누가 책임지든 간에 정책이 결정하는 것이며, AI가 그 정책을 작성했습니다.

해결책 (The Fix)

RLS는 계속 활성화 상태로 유지하고, 각 작업을 위한 하나의 정책을 작성하여 모든 행을 auth.uid()를 가진 로그인 사용자에게 연결해야 합니다. 삽입 오류(insert error)는 거의 항상 전송된 행에 호출자(caller)와 일치하는 user_id가 없다는 것을 의미하므로, 정책이 아닌 데이터를 수정해야 합니다.

alter table public.notes enable row level security;

-- 클라이언트가 잊거나 위조할 수 없도록 소유자를 Postgres가 채우게 함
...

주의 깊게 봐야 할 몇 가지 세부 사항들이 있습니다:

• using은 사용자가 볼 수 있거나 변경할 수 있는 기존 행을 결정합니다. with check는 새로 추가되거나 업데이트되는 행이 어떤 형태여야 하는지 결정합니다. 업데이트 작업에는 둘 다 필요하며, 그렇지 않으면 사용자는 자신의 행을 다른 사람의 user_id로 이동시킬 수 있습니다.
• to authenticated는 로그인하지 않은 방문자를 완전히 차단합니다. Supabase 문서에서는 또한 익명 요청(anonymous requests)에 대해 auth.uid()가 null임을 지적하고 있으며, 이 경우 오류를 발생시키기보다는 비교가 조용히 실패합니다.
• auth.uid()를 (select ...)로 감싸면 Postgres가 이를 행당 한 번이 아닌 스테이트먼트당 한 번 평가하도록 합니다. Supabase는 성능을 위해 이를 권장합니다.

클라이언트 측에서는 user_id를 아예 보내지 않고 삽입합니다:

// 기본적으로 호출자의 JWT에서 user_id가 채워집니다
const { error } = await supabase.from('notes').insert({ body: text });

만약 관리자 작업이나 웹훅처럼 진정으로 권한이 높은 접근(elevated access)이 필요한 경우, 호출자를 먼저 검증하는 서버 라우트나 Edge Function에서 처리하고, NEXT_PUBLIC_ 또는 VITE_ 접두사가 없는 서버 전용 환경 변수에서 service_role 키를 읽으십시오.

자체 앱 확인 방법

공격자가 사용할 열쇠와 동일한 키를 사용하십시오. 즉, 사용자 세션이 없는 귀하의 anon key입니다.

curl "https://YOUR_PROJECT_REF.supabase.co/rest/v1/notes?select=*" \
  -H "apikey: $SUPABASE_ANON_KEY" \
  -H "Authorization: Bearer $SUPABASE_ANON_KEY"

만약 이 명령이 행을 반환한다면, 인터넷의 누구나 동일한 행에 접근할 수 있다는 의미입니다. 위의 정책들을 적용하면 []가 반환됩니다. 사용자 데이터를 담고 있는 모든 테이블에 대해 이를 반복하고, 마이그레이션에서 using (true), with check (true) 및 disable row level security를 grep(검색)하십시오.

FAQ

Q: Supabase anon key를 프론트엔드에 노출하는 것이 안전한가요?
A: anon key는 공개되도록 설계되었지만, 이를 도달할 수 있는 모든 테이블이 RLS(Row Level Security)가 활성화되어 있고 호출자에게 행을 제한하는 정책을 가지고 있을 때만 안전합니다. 그렇지 않다면, anon key는 데이터에 대한 읽기 및 쓰기 키가 됩니다.

Q: RLS를 비활성화하지 않고 'new row violates row-level security policy' 오류는 어떻게 수정하나요?
A: 삽입된 행의 user_id가 auth.uid()와 일치하는지 확인하세요. 이상적으로는 해당 컬럼의 기본값(default)을 auth.uid()로 설정하고, authenticated 역할을 위해 with check ((select auth.uid()) = user_id)를 포함하는 삽입 정책(insert policy)을 추가해야 합니다.

Q: USING (true)는 언제 허용되나요?
A: 국가 목록이나 게시된 블로그 글처럼 진정으로 공개적인 테이블에 대한 SELECT 작업일 경우에만 허용됩니다. INSERT, UPDATE 또는 DELETE에는 절대 사용해서는 안 되며, 사용자 데이터가 포함된 테이블에는 절대로 사용할 수 없습니다.

저는 이 작업을 위해 SafeWeave를 실행해 왔습니다. 이 저장소(repo)는 RLS가 비활성화되었는지(supabase-rls-disabled), 항상 참인 정책(supabase-rls-passthrough-policy), 그리고 NEXT_PUBLIC_ 또는 VITE_ 변수에 있는 서비스 역할 키(service_role key)를 확인합니다. 또한, 읽기 전용 라이브 검사(read-only live check)는 배포된 앱에 대해 동일한 익명 키(anon-key) 테스트를 실행하여 누구나 읽을 수 있는 테이블을 찾아냅니다. 이러한 검사는 Cloud 플랜에서 제공되며, 무료 티어에서는 개수만 보여줍니다. 스캐너가 없더라도 위 cURL 테스트와 using (true)에 대한 grep 검색만으로 대부분의 문제를 포착할 수 있습니다. 중요한 것은 사용자 데이터가 유출되기 전에 이를 발견하는 것입니다.