후크
Supabase 프로젝트를 보호하려면 API 키 관리, 데이터베이스 보안 및 스토리지 권한에 초점을 맞춘 다층 접근 방식이 필요합니다. [S1] 행 수준 보안(RLS)이 부적절하게 구성되거나 민감한 키가 노출되면 심각한 데이터 노출 사고가 발생할 수 있습니다. [S2] [S3]
달라진 점
이 연구에서는 공식 아키텍처 지침을 기반으로 Supabase 환경에 대한 핵심 보안 제어를 통합합니다. [S1] 특히 액세스 제어 메커니즘과 관련하여 기본 개발 구성에서 프로덕션 강화 상태로의 전환에 중점을 둡니다. [S2] [S3]
영향을 받는 사람
Supabase를 서비스형 백엔드(BaaS)로 활용하는 애플리케이션, 특히 사용자별 데이터나 개인 자산을 처리하는 애플리케이션이 영향을 받습니다. [S2] 클라이언트 측 번들에 service_role 키를 포함하거나 RLS를 활성화하지 못하는 개발자는 위험이 높습니다. [S1]
문제의 작동 방식
Supabase는 PostgreSQL의 행 수준 보안을 활용하여 데이터 액세스를 제한합니다. [S2] 기본적으로 RLS가 테이블에서 활성화되지 않은 경우 일반적으로 공개되는 anon 키를 가진 모든 사용자는 모든 레코드에 액세스할 수 있습니다. [S1] 마찬가지로, Supabase 스토리지에는 파일 버킷에서 작업을 수행할 수 있는 사용자 또는 역할을 정의하는 명시적인 정책이 필요합니다. [S3]
공격자가 얻는 것
공개 API 키를 소유한 공격자는 RLS가 누락된 테이블을 악용하여 다른 사용자에게 속한 데이터를 읽거나 수정하거나 삭제할 수 있습니다. [S1] [S2] 스토리지 버킷에 대한 무단 액세스로 인해 개인 사용자 파일이 노출되거나 중요한 애플리케이션 자산이 삭제될 수 있습니다. [S3]
FixVibe가 이를 테스트하는 방법
FixVibe는 이제 Supabase 검사의 일부로 이 문제를 다룹니다. baas.supabase-security-checklist-backfill는 공개 Supabase 스토리지 버킷 메타데이터, 익명 객체 목록 노출, 민감한 버킷 이름 지정 및 공개 익명 경계의 익명 스토리지 신호를 검토합니다. 관련 라이브 검사에서는 서비스 역할 키 노출, Supabase REST/RLS 상태, 누락된 RLS에 대한 리포지토리 SQL 마이그레이션을 검사합니다.
고쳐야 할 점
항상 데이터베이스 테이블에서 행 수준 보안을 활성화하고 인증된 사용자에 대해 세부적인 정책을 구현하십시오. [S2] 클라이언트측 코드에서는 'anon' 키만 사용하고 'service_role' 키는 서버에 남아 있는지 확인하세요. [S1] 파일 버킷이 기본적으로 비공개이고 정의된 보안 정책을 통해서만 액세스가 허용되도록 스토리지 액세스 제어를 구성합니다. [S3]