ClearedToShip
high

Supabase RLS 모범 사례

문제점

RLS를 켜는 것은 절반의 작업일 뿐입니다. 느슨하거나 잘못된 정책은 RLS가 '켜져' 있어도 데이터를 노출된 채로 둡니다. 이것이 Supabase 행 수준 보안이 실제로 당신의 데이터를 보호하게 만드는 사례입니다.

단계별 안내

  1. 1

    기본은 거부, 허용은 명시적으로

    모든 테이블에 RLS를 켜서 기본적으로 접근이 거부되게 하고, 그다음 좁은 정책을 추가하세요. 비공개 데이터가 있는 테이블에는 'true' / 모두 허용 정책을 절대 쓰지 마세요.

  2. 2

    정책을 사용자 범위로 한정하기

    auth.uid()를 사용해 행을 소유자로 제한하세요. 예: USING (auth.uid() = user_id). 작업(select/insert/update/delete)별로 별도의 정책을 작성하고, 쓰기에는 WITH CHECK를 사용하세요.

  3. 3

    권한 상승으로부터 보호하기

    service-role 키는 서버 측에만 두세요 — RLS를 우회합니다. 정책을 우회해 데이터를 새어 나가게 하는 뷰나 SECURITY DEFINER 함수를 노출하지 마세요.

  4. 4

    익명과 사용자로 각각 테스트하기

    익명 요청은 아무것도 반환하지 못하고, 한 사용자가 다른 사용자의 행을 읽거나 쓸 수 없는지 확인하세요. 무료 RLS 검사를 다시 실행해 확인하세요.

고치는 것을 넘어, 확인까지 받고 싶으신가요?

고치는 것은 첫 단계일 뿐입니다. ClearedToShip 검토는 수정이 실제로 유효한지 확인하고, 출시할 수 있도록 서명되고 보험으로 보증된 승인을 제공합니다. 얼리 액세스를 신청하세요:

무료 출시 준비도 검사
무료 검사 받기