3줄 요약
- UpGuard는 Supabase DB 16,326개에서 읽을 수 있는 테이블을 찾았고 절반이 넘는 DB에서 개인정보 필드를 확인했다.
- 이름·이메일·전화번호·주소가 주로 드러났고, 비밀번호·PIN(8.2%)과 인증 정보(9.7%)는 상대적으로 적었다. 일부 사례에서는 평문 비밀번호와 OTP 문자, 개인 메시지도 드러났다.
- 내 프로젝트는 테이블별 RLS와 정책, Database → Security Advisor 경고, service_role·secret 키 보관 위치를 확인한다.
보안업체 UpGuard가 Supabase로 운영되는 데이터베이스 16,326개에서 읽을 수 있는 테이블을 발견했다. 그중 절반이 넘는 곳에서 개인정보 필드가 확인됐고, 이름·이메일·전화번호·주소가 주로 드러났고, 비밀번호·PIN(8.2%)과 인증 정보(9.7%)는 상대적으로 적었다. 일부 사례에서는 평문 비밀번호와 OTP 문자, 개인 메시지도 드러났다. 원인은 데이터베이스 자체의 침해라기보다 앱을 만들고 공개할 때 접근 권한을 잘못 설정한 데 있었다.
Supabase는 웹·앱 개발자가 데이터베이스를 저장하고 운영하는 개발 플랫폼이다. TechCrunch는 9월 26일 새벽(한국 시간 02:29) 이 조사를 보도하며, AI가 만든 코드를 빠르게 배포하는 바이브 코딩 흐름에서 보안 설정을 놓칠 수 있다고 짚었다.
1만 6천 개 DB에서 무엇이 드러났나
UpGuard는 Supabase 사용 흔적이 있는 약 30만 개 도메인을 모으고, 공개 JavaScript에서 데이터베이스 주소를 찾은 뒤 흔한 테이블 이름인 users를 조회했다. 그 결과 읽을 수 있는 테이블이 있는 DB 16,326개를 집계했다. 테이블 스키마를 살펴보니 55.8%에 개인정보 필드가 있었고, 일부 사례는 실제 데이터 노출도 확인됐다.
테이블 기준으로 이름 필드는 42.8%, 이메일 38.8%, 전화번호 25.8%, 주소 16.0%에서 나타났다. 결제 연동 정보는 12.1%였으며 카드 번호가 아니라 Stripe 같은 결제 서비스의 참조 ID를 뜻한다. 인증 정보는 9.7%, 비밀번호·PIN은 8.2%, 생년월일은 3.6%였다.
도표는 UpGuard 보고서의 데이터 유형별 집계다. 출처: UpGuard.
업종별로 보면
쇼핑몰·소매 분야에서는 전화번호가 48.5%, 주소가 38.4%로 나타났고, 음식점 DB에서는 전화번호가 47.0%였다. 도박·산업재 분야는 비밀번호 비중이 각각 13.4%, 11.9%로 상대적으로 높았다.
실제 데이터가 드러난 사례
- 미국 발렛 서비스에서 차량 번호판 수천 개가 노출됐다.
- 이민·이주 서비스 이용자 연락처가 드러났고, 캐나다 이민 서비스 사례에서는 비밀번호가 평문 그대로 저장돼 있었다.
- 프랑스에 있는 아프리카 국가 영사관의 정보도 노출 사례에 포함됐다.
- 필리핀 가상 SIM 서비스의 데이터베이스에서는 OTP 문자가 노출돼 스캠용 SMS 가로채기에 이용됐다.
- 인도 성인 콘텐츠 서비스에서는 이용자 정보와 개인 메시지가 노출됐다.
RLS와 접근 정책 설정이 중요한 이유
Supabase 데이터베이스는 Row Level Security(RLS)로 사용자가 어떤 행을 읽고 바꿀 수 있는지 제어한다. RLS가 꺼져 있거나, 정책이 모든 사용자에게 열려 있거나, 공개용 키와 비밀 키를 혼동하면 의도하지 않은 데이터 접근이 가능해진다. Table Editor에서 만든 테이블은 RLS가 기본으로 켜지지만 SQL이나 API로 만든 테이블은 직접 켜야 한다.
AI가 생성한 코드로 앱을 빨리 만드는 과정에서 개발자가 이 설정을 충분히 살피지 않고 배포할 수 있다는 점이 이번 보도가 지적한 바이브 코딩의 보안 과제다.
Supabase의 입장
Supabase CISO Bil Harmer는 TechCrunch에 프로젝트는 기본적으로 안전하게 만들어졌으며 보안은 Supabase와 고객이 함께 책임진다고 설명했다. 회사는 안전한 기본값과 도구를 제공하고 고객이 프로젝트 구성을 통제하며, 보안 문제가 발견되면 영향을 받은 고객에게 알린다는 입장이다. 개발자가 안전하게 배포할 수 있도록 계속 개선하겠다고 덧붙였다.
바이브 코딩과 함께 커진 Supabase
Supabase는 2026년 6월 Series F에서 5억 달러를 유치하며 투자 전 기업가치 100억 달러를 인정받았다. 바이브 코딩으로 앱을 만들어 올리는 개발자가 늘어난 덕분이다. 이용이 넓어질수록 데이터베이스 권한 설정을 확인하는 일도 더 중요해진다.
내 Supabase 프로젝트 점검 3단계
- 테이블별로 RLS와 정책을 확인한다. Dashboard의 Database → Tables에서 테이블을 살피고, Database → Policies에서 정책을 확인한다. SQL Editor나 마이그레이션으로 만든 테이블은 RLS를 직접 켠다.
alter table public.profiles enable row level security;로그인한 사용자가 자기 프로필만 읽고 수정하는 정책 예시는 다음과 같다.
profiles.user_id에 사용자 UUID가 저장된다고 가정한다.create policy "Users can read their own profile" on public.profiles for select to authenticated using ((select auth.uid()) = user_id); create policy "Users can update their own profile" on public.profiles for update to authenticated using ((select auth.uid()) = user_id) with check ((select auth.uid()) = user_id);USING (true)처럼 모두에게 읽기를 허용하는 정책은 실제 공개 데이터에만 사용한다. - Security Advisor 경고를 확인한다. Dashboard의 Database → Security Advisor에서 RLS 비활성화, 정책 누락, 지나치게 넓은 정책, 민감 열 노출 경고를 살핀다. 수정한 뒤 다시 실행한다.
- 클라이언트에 비밀 키를 넣지 않는다.
anon·publishable키는 공개 클라이언트에서 사용할 수 있지만 데이터 접근은 RLS 정책으로 제한해야 한다.service_role·secret키는 RLS를 우회하므로 브라우저·앱 코드나 공개 저장소에 넣지 말고 서버에서만 사용한다.
공식 문서: Row Level Security, Securing your API, Database Advisors, API keys, Production Checklist.
Supabase로 만든 앱이 있다면 오늘 Security Advisor를 한 번 열어 보세요. 빨간 경고가 뜬 테이블부터 RLS를 켜면 됩니다.
