영향
행 수준 보안(RLS) 구현 실패로 인해 공개 테이블이 익명 경계 [S1]를 통해 노출될 때 인증되지 않은 공격자가 Supabase 데이터베이스에서 데이터를 쿼리할 수 있습니다. Next.js 애플리케이션은 일반적으로 클라이언트 측 코드에서 Supabase anon 키를 노출하므로 공격자는 이 키를 사용하여 데이터베이스에 대한 직접 REST API 호출을 수행하여 의도된 애플리케이션 로직을 우회하고 민감한 사용자 정보에 액세스할 수 있습니다. [S2].
근본 원인
기본적으로 Supabase의 Postgres 테이블에는 공개 액세스 [S1]를 방지하기 위해 행 수준 보안의 명시적인 활성화가 필요합니다. 개발자가 테이블을 생성했지만 RLS 활성화를 잊어버리거나 제한적인 정책을 정의하지 못한 경우 데이터베이스는 프로젝트의 anon 키 [S1]를 소유한 모든 사람에게 데이터를 노출할 수 있습니다. Next.js 애플리케이션에서 서버 측 렌더링 및 클라이언트 측 가져오기에는 인증된 사용자 컨텍스트가 데이터베이스 계층 [S2]에 도달하도록 주의 깊은 Supabase 클라이언트 설정이 필요합니다.
구체적인 수정
- RLS 활성화: 앱 데이터 [S1]를 저장하는 모든 공개 테이블에 대해
ALTER TABLE "your_table_name" ENABLE ROW LEVEL SECURITY;를 실행합니다. - 정책 정의:
CREATE POLICY "Users can see their own data" ON your_table_name FOR SELECT USING (auth.uid() = user_id);[S1]와 같이 사용자의 인증 상태에 따라 액세스를 제한하는 특정 정책을 만듭니다. - 보안 서버 측 클라이언트: Next.js를 사용할 때 서비스 역할 클라이언트를 서버 전용으로 유지하고 사용자 [S2]에게 데이터를 반환하기 전에 소유권 필터를 계속 적용합니다.
FixVibe가 이를 테스트하는 방법
FixVibe는 이미 baas.supabase-rls를 통해 읽기 전용 Supabase RLS 검사를 실행하고 있습니다. 스캐너는 동일한 원본 JavaScript 번들에서 Supabase 프로젝트 URL 및 공개 익명 키를 검색하고, PostgREST에 공개 테이블 메타데이터를 요청하고, 제한된 읽기 전용 선택을 시도하여 사용자 세션 없이 데이터가 노출되는지 확인합니다. 서비스 역할 자격 증명을 삽입, 업데이트, 삭제 또는 사용하지 않습니다. Repo 스캔은 ENABLE ROW LEVEL SECURITY 없이 공개 테이블을 생성하는 SQL 마이그레이션에 플래그를 지정하는 repo.supabase.missing-rls를 통해 이를 더 일찍 포착할 수도 있습니다.