RLS 켜놨으니 안전하다? 정책이 문제다

Supabase를 쓰는 바이브코딩 프로젝트에서 "RLS 활성화했으니 보안 OK"라고 생각하는 경우가 많다. 하지만 RLS를 켜는 것과 올바른 정책을 설정하는 것은 완전히 다른 문제다.

CodeScan에서 Supabase 프로젝트 40개를 분석한 결과, RLS를 켠 프로젝트 중 80%에서 정책 우회가 가능했다.

패턴 1: 너무 느슨한 SELECT 정책

AI가 가장 많이 생성하는 RLS 패턴이다:

-- AI가 만든 정책
CREATE POLICY "Users can view own data" ON profiles
  FOR SELECT USING (true);  -- 모든 사용자가 모든 데이터를 볼 수 있음

USING (true)는 "모든 행에 접근 허용"이라는 뜻이다. AI는 "일단 돌아가게" 만들고, 정책을 세밀하게 설정하지 않는다. 이 상태에서 다른 사용자의 이메일, 전화번호, 결제 정보가 모두 조회된다.

올바른 정책:

CREATE POLICY "Users can view own data" ON profiles
  FOR SELECT USING (auth.uid() = user_id);

RLS를 아무리 잘 설정해도 소용없는 경우가 있다. service_role 키는 RLS를 완전히 우회하기 때문이다.

AI가 생성한 코드에서 NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY처럼 클라이언트 환경변수로 service_role 키를 설정하는 경우가 있다. 이러면 브라우저에서 이 키를 꺼내 모든 데이터에 접근할 수 있다.

규칙: service_role 키는 서버 측에서만, anon 키만 클라이언트에 노출한다.

-- 위험한 INSERT 정책
CREATE POLICY "Users can insert" ON posts
  FOR INSERT WITH CHECK (true);

이 정책은 누구나 데이터를 삽입할 수 있고, user_id를 다른 사용자의 ID로 설정할 수도 있다. 다른 사용자 이름으로 글을 쓰거나, 관리자 권한을 자기에게 부여하는 것이 가능하다.

올바른 정책:

CREATE POLICY "Users can insert own" ON posts
  FOR INSERT WITH CHECK (auth.uid() = user_id);

AI가 SELECT, INSERT 정책은 만들지만 DELETE, UPDATE 정책을 빠뜨리는 경우가 많다. RLS가 켜진 상태에서 정책이 없으면 기본적으로 차단되지만, AI가 "에러 나니까"라며 USING (true) 정책을 추가하는 패턴이 반복된다.

Supabase 대시보드에서 RLS 정책을 하나씩 검토하는 것도 방법이지만, 배포된 사이트 전체를 외부에서 자동 점검하면 API 키 노출, 보안 헤더 누락까지 한 번에 잡을 수 있다.