Supabase 데이터 노출, 바이브 코딩 앱의 보안 주장에 압박

Supabase는 프로젝트가 기본적으로 안전하게 구성된다고 설명해 왔음에도, 연구진이 공개적으로 읽을 수 있는 테이블을 가진 데이터베이스 16,326개를 확인한 뒤 검증의 대상이 되고 있다. Supabase 데이터 노출 조사 결과는 익숙한 클라우드 보안 문제를 AI 코딩 도구로 빠르게 조립된 앱이라는 새로운 위험 요인과 연결한다.

UpGuard는 노출된 데이터베이스 가운데 절반 이상에서 개인정보를 시사하는 징후를 발견했다. 영향받은 기록에는 이름, 주소, 전화번호, 생년월일, 비밀번호, 인증 토큰, 비공개 메시지, 차량 번호판, 이민 관련 정보가 포함된 것으로 전해졌다.

이는 Supabase 내부 시스템에서 발생한 단일 침해 사고가 아니었다. 대신 증거는 접근 제어가 없거나 불충분해 노출된 고객 데이터베이스를 가리킨다. 이 구분은 중요하지만, 사안의 규모에 대한 우려를 덜어주지는 않는다.

이 보고서는 기술적 구성 실패를 바이브 코딩 모델의 시험대로 바꾼다. AI 어시스턴트는 몇 분 안에 작동하는 인터페이스를 생성하고 호스팅된 데이터베이스에 연결할 수 있다. 그러나 모든 사용자, 테이블, 역할, 작업에 올바른 권한 정책이 적용되도록 안정적으로 보장하지는 못한다.

Supabase 데이터 노출 조사에서 확인된 내용

UpGuard의 핵심 발견은 유난히 부주의한 앱 하나가 아니라, 수천 개의 독립적으로 구축된 프로젝트가 유사한 보안 실수를 반복하고 있다는 점이다.

2026년 9월 조사에서 UpGuard는 Supabase 사용 징후를 보이는 고유 도메인 약 30만 개를 수집했다. 연구진은 BuiltWith와 Chrome User Experience Report 데이터를 활용해 관련 사이트를 식별했다.

이후 각 프로젝트가 users라는 이름의 테이블을 노출하는지 테스트했다. 널리 쓰이는 이 테이블명은 각 애플리케이션의 데이터베이스 설계를 사전에 알 필요 없이 일관된 출발점을 제공했다.

테스트에서는 여러 응답이 나올 수 있었다. 안전하거나 비활성 상태인 데이터베이스는 접근 가능한 데이터를 반환하지 않았다. 일부 데이터베이스는 오류 힌트를 통해 다른 접근 가능한 테이블을 드러냈다. 다른 데이터베이스는 한 페이지 분량의 기록을 반환했다.

이 후보군 전반에서 UpGuard는 읽을 수 있는 테이블이 있는 데이터베이스 16,326개를 식별했다. 회사의 노출 조사에 따르면, 이들 중 절반 이상에는 어떤 형태의 개인식별정보를 시사하는 스키마 필드가 포함돼 있었다.

연구진은 주로 이용 가능한 모든 기록을 내려받기보다 테이블 스키마를 분석했다. 스키마는 열 이름과 데이터 유형을 보여주므로, 테이블에 이메일 주소, 비밀번호, 전화번호 또는 결제 정보가 들어 있는지 가늠할 수 있다.

이 접근 방식은 개인정보 기록에 대한 불필요한 접근을 줄였다. 동시에 16,326개라는 수치가 모든 데이터베이스에 민감한 정보가 포함됐거나 공격자가 이전에 이용 가능한 데이터를 복사했다는 사실을 입증하는 것은 아니라는 의미이기도 하다.

UpGuard는 메타데이터가 의미 있는 노출을 시사한 일부 사례를 조사했다. 이 사례들은 구성 실수가 어떻게 기술 부채의 문제를 넘어 직접적인 개인 피해로 이어질 수 있는지 보여준다.

인도의 한 성인 스트리밍 서비스는 65,467명의 정보를 담은 테이블을 노출했다. 해당 필드에는 신분증 문서, 주소, 생년월일, 금융 계좌, 일부 정부 발급 식별번호가 포함된 것으로 알려졌다. 또 다른 테이블에는 콘텐츠 제작자와 관련된 비공개 메시지 10만 건 이상이 저장돼 있었다.

필리핀의 한 가상 SIM 운영사는 사용자 2,000명 이상과 문자 메시지 10만 건 이상에 관한 정보를 노출했다. 대부분의 메시지는 일회용 인증번호를 담고 있었지만, 표본에는 차량 호출 서비스 기사와 승객 간의 일반적인 대화 수천 건도 포함돼 있었다.

미국의 한 발레파킹 서비스는 고객 10만 명 이상과 관련된 기록을 노출했다. 데이터베이스에는 약 7만 8,000개의 차량 번호판 번호, 약 4만 3,000개의 이메일 주소, 방문 이력, 팁 정보, 자유 입력 메모가 포함돼 있었다.

연구진은 또한 기록 2만 5,000건을 포함한 아프리카 한 정부 영사관의 데이터베이스도 발견했다. 일부 항목은 잠재적으로 취약한 집단에 속한 사람들의 긴급 주거 위치를 식별했다.

캐나다의 한 이민 서비스는 약 5,000건의 기록을 노출했다. UpGuard는 이 가운데 884건에 평문으로 저장된 비밀번호가 포함돼 있어, 해당 애플리케이션이 접근 제어와 비밀번호 처리 모두에서 실패했다고 밝혔다.

이 사례들은 더 넓은 결론을 뒷받침하는 동시에 여러 층위의 실패를 드러낸다. 공개 테이블 접근이 문을 열었지만, 취약한 애플리케이션 설계가 데이터 내용을 더 위험하게 만들었다.

원 보도에 따르면, 영향을 받은 데이터세트 대부분은 미국과 연결된 것으로 보였다. 그럼에도 UpGuard는 전 세계에서 노출된 프로젝트를 발견했으며, 문제를 전 세계적 현상으로 설명했다.

지리적 확산은 Supabase가 소규모 애플리케이션, 신생 기업, 기존 조직에 공통 인프라로 사용된다는 점에서 중요하다. 따라서 반복되는 하나의 구성 패턴이 여러 산업과 법적 관할권에 걸쳐 서로 관련 없는 사용자에게 영향을 미칠 수 있다.

데이터베이스가 웹에서 접근 가능했던 이유

Supabase 애플리케이션에 포함된 공개 키 자체가 반드시 취약점은 아니다. 결정적인 통제 수단은 그 키에 허용된 작업이다.

Supabase는 인증, 스토리지, 자동 생성 데이터 인터페이스와 함께 호스팅된 PostgreSQL 데이터베이스를 제공한다. 웹 애플리케이션은 publishable key를 사용해 Data API를 통해 요청을 보낼 수 있다.

개발자들은 때때로 브라우저 코드에서 이 키를 발견하는 것만으로 키가 유출됐다고 생각한다. Supabase는 웹사이트와 모바일 애플리케이션을 포함한 공개 클라이언트용으로 publishable key를 명시적으로 설계했다.

실질적인 보호는 권한 부여와 보통 RLS로 줄여 부르는 Row Level Security에서 나온다. RLS는 개별 행을 반환하거나 변경하기 전에 데이터베이스 내부에서 권한 규칙을 적용하는 PostgreSQL 기능이다.

로그인한 사용자는 자신의 식별자를 지닌 기록만 읽을 권한을 받을 수 있다. 로그인하지 않은 방문자는 전혀 접근 권한을 받지 못할 수 있다. 또 다른 정책은 의도적으로 공개한 제품 카탈로그를 모든 사람이 읽을 수 있도록 허용할 수 있다.

Supabase의 보안 문서는 개발자가 노출된 테이블에 RLS를 활성화하고 최소 권한 원칙에 따라 정책을 구성해야 한다고 설명한다. publishable key는 이러한 통제가 접근을 정확히 제한할 때에만 안전한 것으로 간주된다.

플랫폼은 신뢰할 수 있는 백엔드 시스템용 secret 또는 service-role key도 제공한다. 이 키들은 RLS를 우회하므로 브라우저, 배포된 애플리케이션, 공개 저장소에 절대 포함돼서는 안 된다.

이 아키텍처는 미묘한 보안 경계를 만든다. 보이는 publishable key는 예상된 것이지만, 인증되지 않은 방문자에게도 데이터베이스가 anon 역할에 허용한 모든 항목에 이르는 경로를 제공한다.

테이블에 RLS가 없거나, 과도한 권한이 부여됐거나, 모든 행을 허용하는 정책을 사용한다면 외부인은 정상 앱이 사용하는 것과 동일한 인터페이스를 통해 쿼리할 수 있다. 정교한 침입은 필요하지 않다.

UpGuard 연구진은 공개적으로 제공되는 JavaScript에서 Supabase 식별자를 살펴 대상 프로젝트를 찾았다. 이후 각 데이터베이스에 공통 테이블이 공개 인터페이스를 통해 이용 가능한지 물을 수 있었다.

이 기법은 일반적인 애플리케이션 동작과 닮아 있다. 차이는 누가 요청을 보내는지, 그리고 데이터베이스가 허가된 사용자와 인터넷상의 다른 모든 사람을 구분할 수 있는지에 있다.

Supabase의 상세한 RLS 지침은 노출된 스키마의 테이블이 RLS가 없고 요청 역할에 적절한 권한이 부여된 경우 읽기 또는 쓰기가 가능할 수 있다고 경고한다. 익명 역할과 인증 역할 모두에 대해 허용된 작업과 거부된 작업을 테스트할 것을 권고한다.

이 때문에 publishable key만 교체한다고 근본 문제가 해결되지는 않는다. 새 키도 클라이언트에서 계속 가져올 수 있으며, 결함이 있는 데이터베이스 정책은 여전히 접근 권한을 부여한다.

대신 개발자는 노출된 스키마, 테이블 권한, RLS 상태, 정책 조건, 데이터베이스 뷰, 서버 자격 증명을 검토해야 한다. 또한 사용자가 다른 사용자의 기록을 읽거나 변경할 수 없음을 확인하는 테스트도 필요하다.

뷰에는 특히 주의해야 한다. PostgreSQL 뷰는 기본적으로 소유자를 통해 권한을 평가할 수 있어, 기반 테이블을 보호하는 제한을 우회할 가능성이 있다. 따라서 프로젝트가 모든 곳에서 RLS를 활성화했더라도 안전하지 않은 뷰를 통해 데이터를 노출할 수 있다.

같은 구분은 인증에도 적용된다. 누군가에게 로그인을 요구한다고 해서 테넌트가 자동으로 분리되는 것은 아니다. 정책이 유효한 세션만 확인한다면 모든 인증 사용자가 여전히 광범위한 접근 권한을 얻을 수 있다.

따라서 키 수준에서 설명하는 Supabase 보안은 단순하다. 공개 클라이언트에는 공개 식별자가 필요하고, 실제 경계는 데이터베이스 정책이 적용한다. 어려움은 애플리케이션이 의도한 규칙을 완전하고 검증된 정책으로 옮기는 데 있다.

바이브 코딩은 구성 공백을 반복되는 패턴으로 만든다

AI 어시스턴트가 눈에 보이는 결과를 최적화하는 반면 권한 부여는 이를 지시하는 사람에게 보이지 않는 상태로 남을 때, 바이브 코딩 보안 위험은 커진다.

기존 개발팀도 데이터베이스를 잘못 구성할 수 있다. 공개 Amazon S3 버킷, 노출된 Elasticsearch 클러스터, 유출된 클라우드 자격 증명은 생성형 AI가 소프트웨어 개발에 등장하기 오래전부터 존재했다.

바이브 코딩으로 달라지는 점은 속도, 접근성, 제한적인 검토의 결합이다. 사람은 자연어로 앱을 요청하고, 생성된 코드를 받아들이고, 호스팅된 백엔드에 연결해 신뢰 경계를 이해하지 못한 채 배포할 수 있다.

등록이 작동하고, 기록이 올바르게 저장되며, 페이지가 로드되기 때문에 애플리케이션은 완성된 것처럼 보일 수 있다. 이 테스트는 기능을 확인한다. 그러나 한 계정이 다른 계정의 기록을 쿼리할 수 없는지는 확인하지 않는다.

권한 부여 실패는 정상 경로 시연에서 특히 놓치기 쉽다. 개발자는 로그인 후 예상한 프로필을 보고 시스템이 이를 보호했다고 가정한다. 공격자는 다른 질문을 한다. 요청에서 세션을 생략하거나 기록 식별자를 바꾸면 어떻게 되는가?

AI 코딩 에이전트는 인프라와도 프로그래밍 방식으로 상호작용한다. UpGuard는 Supabase가 대시보드의 일부 기능을 통해 생성된 테이블에는 기본적으로 RLS를 활성화하지만, 프로그래밍 방식으로 생성된 테이블에는 추가 주의가 필요하다고 지적했다.

이 차이는 에이전트가 SQL이나 API를 통해 데이터베이스 스키마를 생성할 때 중대한 결과를 낳을 수 있다. 하나의 생성 워크플로에 연결된 보호 설정이 플랫폼으로 들어가는 모든 경로를 자동으로 포괄하지는 않는다.

Supabase는 2025년 보안 검토에서 이처럼 더 광범위한 사용성 과제를 인정했다. 회사는 RLS가 유연하지만 이 패턴에 익숙하지 않은 개발자에게는 복잡할 수 있다고 밝혔다.

2025년 동안 Supabase는 더 안전한 기본값을 추가하고 Security Advisor를 확장했다. 또한 프로젝트에 Data API에 대한 더 많은 제어권을 부여했으며, 기본 public 스키마 대신 이를 비활성화하거나 사용자 지정 스키마를 노출하는 옵션도 포함했다.

이러한 변화는 도움이 되지만 기존 프로젝트를 지우거나 생성된 모든 마이그레이션을 수정하지는 않는다. 보안 도구는 일반적인 오류를 표시할 수 있지만, 기본 검사를 통과하면서도 정책이 논리적으로 잘못된 상태로 남을 수 있다.

생성된 규칙은 잘못된 식별자를 비교하거나, 업데이트 경로를 간과하거나, 읽기는 보호하면서 무단 쓰기를 허용할 수 있다. 하나의 테이블에서는 작동하지만 연결된 테이블은 공개 상태로 남길 수도 있다.

인간 감독자는 이러한 누락된 동작이 존재한다는 사실을 인지해야 한다. RLS, 역할 권한 부여, 테넌트 격리를 모르는 초보자는 모델에게 이를 테스트해 달라고 요청조차 하지 않을 수 있다.

이로 인해 구축과 감사 사이에는 비대칭이 생긴다. 기능을 생성하는 데는 프롬프트 하나면 충분하다. 그러나 그 기능이 모든 신원과 작업을 안전하게 처리한다는 것을 입증하려면 위협 모델, 부정 테스트, 생성된 결과물에 대한 세심한 검토가 필요하다.

이전 연구들은 이것이 고립된 설문 결과가 아니라 반복되는 패턴임을 시사한다. UpGuard는 Y Combinator 기업, AI 개발 플랫폼으로 제작된 앱, 독립 사이트를 대상으로 한 연구를 인용했다.

Modern Pentest는 조사한 107개 Y Combinator 스타트업 가운데 28%가 Supabase 구성으로 인해 개인정보를 노출했다고 보고했다. 또 다른 연구는 바이브 코딩으로 제작된 앱 1,072개를 검토해, 공개 Supabase 키로 읽을 수 있는 테이블을 가진 앱 39개를 발견했다.

표본과 방법이 서로 다르므로 이 비율들을 합산해서는 안 된다. 그러나 각 조사는 동일한 실패의 변형을 발견했다. 즉, 클라이언트에 노출되는 연결 정보와 애플리케이션 의도보다 광범위한 데이터베이스 권한이 결합된 경우다.

2026년 2월의 한 사건은 그 결과를 특히 뚜렷하게 보여줬다. 보안 기업 Wiz는 AI 에이전트용 플랫폼으로 소개된 소셜 네트워크 Moltbook의 Supabase 백엔드가 잘못 구성되어 있음을 발견했다.

Moltbook 조사에 따르면, 해당 데이터베이스는 플랫폼 데이터에 대한 읽기 및 쓰기 접근을 허용했다. 노출된 자료에는 이메일 주소 3만 5,000개와 API 인증 토큰 150만 개가 포함됐다.

Wiz는 비침해적 평가 과정에서 클라이언트 측 JavaScript를 검토하다가 이 문제를 발견했다고 밝혔다. Moltbook 팀은 공개 통지 후 수 시간 내에 데이터베이스를 보호했다.

이 사건은 현재의 트레이드오프를 간결하게 보여준다. AI 지원은 빠르게 주목받는 서비스를 만드는 데 도움이 됐지만, 애플리케이션의 가시적 성공은 치명적인 데이터베이스 제어 실패를 가리고 있었다.

AI로 구축된 소프트웨어를 평가하는 조직에 이는 작동하는 프로토타입의 의미를 바꾼다. AI가 누군가가 그 아래의 보안 모델을 검증하기 전에 눈에 보이는 워크플로를 완성할 수 있기 때문에, 이제 데모가 프로덕션 준비 상태를 증명하는 정도는 줄어든다.

내부 엔지니어링 지식 베이스는 팀이 아키텍처 결정과 검토 증거를 보존하는 데 도움이 될 수 있다. 데이터베이스 테스트를 대체할 수는 없지만, 보안 가정이 프롬프트와 인수인계 과정에서 사라지는 것을 막을 수 있다.

“기본적으로 안전”과 공동 책임의 만남

핵심 충돌은 안전한 플랫폼 기본값과, 결과가 중대한 설정을 여전히 경험 부족 고객이 제어하게 하는 공동 책임 모델 사이에 있다.

Supabase 최고정보보안책임자 Bil Harmer는 TechCrunch에 논평하기 전 회사가 UpGuard의 연구를 검토하지 않았다고 밝혔다. 그는 Supabase 프로젝트는 기본적으로 안전하며, 보안은 공동 책임이라고 설명했다.

이 입장은 표준적인 클라우드 모델을 반영한다. 제공업체는 호스팅 플랫폼을 보호하고 접근 제어를 제공한다. 고객은 어떤 사용자와 애플리케이션이 자신의 데이터에 접근해야 하는지를 결정한다.

이 구분은 타당하다. UpGuard는 Supabase의 기업 시스템을 침해했거나 올바르게 구성된 RLS 정책을 우회했다고 보고하지 않았다. 노출된 데이터베이스는 설정상 더 광범위한 접근을 허용한 고객 소유였다.

그러나 기본값은 프로젝트 생성 시점만으로 평가할 수 없다. 여기에는 사람과 코딩 에이전트가 테이블을 만들고, API를 공개하고, 예제를 복사하고, 애플리케이션을 배포하는 실질적인 경로도 포함된다.

시스템은 안전하게 시작했더라도 에이전트가 생성한 마이그레이션을 통해 나중에 노출될 수 있다. 또한 안전한 대시보드 워크플로를 제공하면서도 프로그래밍 방식의 워크플로에서는 다른 보안 상태를 만들 수 있다.

따라서 “기본적으로 안전”이라는 표현에는 명확한 경계가 필요하다. 새 프로젝트가 아무것도 노출하지 않는다는 뜻인가? 지원되는 모든 테이블 생성 경로를 포괄하는가? RLS 없는 테이블에 프로덕션 데이터가 들어가기 전에 사용자에게 경고하는가?

공동 책임은 각 당사자가 자신의 역할을 이해한다는 전제도 깔고 있다. 숙련된 클라우드 엔지니어는 공개 클라이언트 식별자가 서버 측 권한 부여와 결합되어야 한다는 사실을 안다. 많은 바이브 코더는 그렇지 않다.

이 지식 격차가 고객 실수에 대한 플랫폼의 단독 책임을 의미하지는 않는다. 하지만 Supabase와 AI 코딩 제공업체가 안전하지 않은 상태를 만들기 어렵고 발견하기 쉽게 해야 한다는 압력을 높인다.

플랫폼은 이미 그 방향으로 움직이고 있다. Supabase의 Security Advisor는 일반적인 데이터베이스 문제를 점검하며, 프로덕션 체크리스트는 사용자에게 모든 관련 테이블에서 RLS를 활성화하고 정책을 검토하라고 안내한다.

더 엄격한 설계라면 보호되지 않은 테이블의 프로덕션 접근을 차단하거나 명시적인 재정의를 요구할 수 있다. 이런 조치는 우발적 노출을 줄이겠지만, 정당한 공개 데이터세트와 빠른 개발을 방해할 수도 있다.

Supabase는 모든 공개 테이블을 취약점으로 취급하지 않으면서 이러한 사례의 균형을 맞춰야 한다. 식당 메뉴, 공개 리더보드 또는 공개 디렉터리는 익명 읽기를 합리적으로 허용할 수 있다.

플랫폼은 테이블 이름만으로 의도를 추론할 수 없다. users 테이블은 products 테이블보다 의심스럽지만, 애플리케이션은 이메일 주소는 비공개로 유지하면서 사용자 프로필을 의도적으로 공개할 수 있다.

자동화 도구도 같은 모호성에 직면한다. 익명 역할이 테이블을 읽을 수 있다는 사실은 감지할 수 있다. 그 접근이 제품의 약속을 위반하는지 판단하려면 비즈니스 맥락이 필요하다.

이것이 핵심 트레이드오프다. 유연한 데이터베이스 정책은 개발자가 다양한 애플리케이션을 만들게 하지만, 그 유연성은 조용한 실수의 여지를 만든다. 규범적인 제한은 실수를 막는 대신 정당한 설계를 제한한다.

AI 어시스턴트는 또 하나의 책임 당사자를 추가한다. 개발자는 에이전트의 추천으로 Supabase를 선택한 뒤, 해당 에이전트가 스키마와 정책을 생성하도록 의존할 수 있다.

모델 제공업체는 데이터베이스를 호스팅하지 않으며, Supabase도 생성되는 모든 명령을 통제하지 않는다. 소유자가 결과적인 권한 부여 모델을 설명할 수 없더라도 앱 소유자는 사용자에 대한 책임을 진다.

이 분절된 사슬은 보안 실패의 책임 소재를 정하기 어렵게 하고 반복되기 쉽게 만든다. 각 참여자는 문서나 다른 당사자의 구성 문제를 지적할 수 있지만, 피해를 입은 사람은 사적인 정보가 공개됐다는 사실만 보게 된다.

엔터프라이즈 구매자에게 실질적인 대응은 전체 개발 시스템을 평가하는 것이다. 공급업체 인증도 중요하지만, 배포 제어, 코드 검토, 데이터베이스 테스트, 로깅, 사고 대응, AI 에이전트를 감독하는 사람들의 경험도 마찬가지로 중요하다.

수치가 보여주는 것과 보여주지 않는 것

이 연구는 큰 노출 표면을 보여주지만, 그 방법론이 확인된 침해 사고 16,326건을 확립하거나 Supabase 전체 고객 기반을 측정하는 것은 아니다.

UpGuard는 플랫폼의 모든 애플리케이션을 무작위로 표본 추출한 것이 아니라, Supabase 사용 징후가 나타나는 도메인에서 조사를 시작했다. 그 출처는 웹 기술 데이터세트를 통해 확인 가능한 사이트에 편중됐다.

연구진은 이후 users라는 이름의 테이블을 조회했다. 많은 애플리케이션이 사용자 기록을 유지하므로 이 선택은 타당했지만, 개인정보를 포함할 가능성이 높은 데이터베이스 쪽으로 조사 범위를 밀어 넣기도 했다.

UpGuard는 이 한계를 공개했다. 이 회사는 사람과 연관된 일반적인 테이블을 의도적으로 선택했기 때문에 결과가 부분적으로 PII에 편중됐다고 밝혔다.

총 16,326건은 읽을 수 있는 테이블을 노출한 데이터베이스를 포괄한다. 모든 테이블이 기밀 기록을 보유했다는 뜻은 아니다. 일부 프로젝트는 의도적으로 데이터를 공개했거나, 합성 정보를 사용했거나, 방치됐을 수 있다.

스키마 분석은 행 단위 포렌식 조사와도 잠재적 노출을 다르게 측정한다. password라는 열 이름은 심각한 경고 신호이지만, 그 존재만으로 활성 자격 증명을 보유했다는 사실이 입증되지는 않는다.

연구진은 선택된 사례를 수동으로 검증하고 해당 데이터베이스의 구체적인 레코드 수를 보고했다. 이 사례들은 적어도 일부 노출이 의미 있는 규모의 실제 민감 데이터를 포함했음을 보여준다.

이 연구는 공개 통지 전 얼마나 많은 외부인이 데이터베이스에 접근했는지도 판단할 수 없다. 공개 접근 가능성은 위험을 만들지만, 범죄 행위자가 해당 정보를 발견하거나 내려받았다는 증거는 아니다.

이 차이는 데이터 노출과 확인된 데이터 침해를 구분한다. 노출은 무단 접근이 가능했다는 뜻이다. 침해는 일반적으로 무단 당사자가 실제로 데이터에 접근하거나 이를 취득했다는 증거를 요구한다.

조직은 이 구분을 사건을 축소하는 데 사용해서는 안 된다. 민감한 기록이 적절한 권한 부여 없이 접근 가능해지면, 조사자는 누가 접근했는지 입증할 충분한 로그를 확보하지 못할 수 있다.

이 연구는 또한 모든 Supabase 프로젝트의 노출률을 계산하지 않았다. UpGuard는 약 30만 개의 후보 도메인을 분석했지만, 하나의 조직이 여러 도메인이나 프로젝트를 운영할 수 있다.

비활성 사이트와 잘못된 기술 지표는 이 분모를 복잡하게 만들 수 있다. 최종 수치는 Supabase 고객의 비율이 아니라 발견된 모집단으로 이해하는 것이 가장 적절하다.

이러한 주의점에도 읽을 수 있는 데이터베이스 16,326개는 상당한 공격 표면을 나타낸다. 악의적 행위자는 같은 일반적인 발견 과정을 자동화하고 가치 있는 필드를 포함한 테이블의 우선순위를 정할 수 있다.

상세 사례는 이들이 무해한 데모 프로젝트였다는 주장도 약화한다. 이민 기록, 긴급 주거 위치, 사적인 성인 간 소통, 차량 번호판, 일회용 암호는 명확한 개인정보 및 안전상 함의를 지닌다.

Supabase의 대응에도 동일한 수준의 정확성이 필요하다. 회사는 보안 문제를 인지하면 영향을 받은 고객에게 알린다고 밝혔다. 이는 몇 개의 프로젝트가 통지받았는지, 얼마나 빠르게 대응했는지, 얼마나 많은 노출이 계속 열려 있었는지를 확인해 주지는 않는다.

UpGuard는 검증한 주요 사례에서 애플리케이션 소유자에게 통지했다고 밝혔다. 공개 보고서는 16,326개 데이터베이스 전체의 완전한 개선 비율을 제공하지 않았다.

이러한 공백은 조사 결과에 대한 보도를 형성해야 한다. 증거는 광범위한 구성 문제와 여러 심각한 노출을 뒷받침한다. 하지만 Supabase 자체가 해킹당했거나 식별된 모든 데이터베이스가 민감한 기록을 유출했다고 주장할 근거는 되지 않는다.

또한 중요한 비교 질문도 남긴다. 연구자들이 동등한 인터넷 규모의 방법을 적용한다면, 비슷한 호스팅 데이터베이스에서도 유사한 문제가 나타날 수 있다.

Firebase, Appwrite, 자체 관리형 PostgreSQL 배포 및 기타 백엔드 서비스는 서로 다른 인터페이스를 노출하고 각기 다른 권한 모델을 사용한다. 개발자는 이들 어느 것이든 잘못 구성할 수 있다.

Supabase가 주목받는 이유는 클라이언트 친화적 아키텍처, 자동 API, AI 코딩 워크플로에서의 인기가 이 문제를 가시화하기 때문이다. 인기는 안전한 배포 수와 실수 수를 모두 늘린다.

따라서 공정한 평가는 Supabase가 데이터를 보호할 능력이 유독 없다는 식의 프레이밍을 피해야 한다. 더 강력한 결론은 경험이 부족한 빌더들 사이의 채택이 접근 제어의 사용성을 플랫폼 수준의 문제로 만든다는 것이다.

위험이 줄어드는지 보여줄 세 가지 신호

다음 단계는 포괄적인 보안 약속이 아니라 측정 가능한 제품 변화, 개선 증거, 독립적인 재검증을 통해 판단해야 한다.

첫 번째 신호는 Supabase가 프로그래밍 방식으로 생성된 테이블을 어떻게 처리하는지다. 코딩 에이전트는 수동 대시보드 클릭보다 SQL, 관리 인터페이스, 자동화된 마이그레이션을 통해 작업하는 경우가 많다.

의미 있는 변화라면 RLS와 제한적인 권한 부여를 생성 경로 전반에 걸쳐 일관되게 적용하거나, 테이블이 Data API를 통해 접근 가능해지기 전에 명시적인 결정을 요구할 것이다. 에이전트 워크플로 내부의 명확한 경고는 이러한 보호를 강화할 것이다.

Supabase가 대시보드 기반 생성과 프로그래밍 방식 생성을 동일한 수준으로 끌어올린다면, 더 안전한 기본 설정이 바이브 코딩의 보안 위험을 줄일 수 있다는 견해를 뒷받침하게 될 것입니다. 워크플로가 계속 다르다면, 경험이 부족한 개발자들은 위험한 상태에 진입하고도 이를 인식하지 못할 가능성이 큽니다.

두 번째 신호는 시정 조치 데이터입니다. Supabase와 UpGuard는 식별된 프로젝트 중 몇 곳이 통지를 받았는지, 몇 명의 소유자가 응답했는지, 그리고 몇 개의 데이터베이스가 의도치 않은 레코드 노출을 중단했는지를 명확히 할 수 있습니다.

높은 시정 조치율은 통지와 보안 도구가 기존 적체를 줄일 수 있음을 보여줄 것입니다. 낮은 비율은 많은 프로젝트가 방치되었거나 유지 관리가 부실하거나, 설정을 수정할 능력이 없는 사람들이 운영하고 있음을 시사할 수 있습니다.

영향을 받은 조직은 노출된 레코드에 대해 사용자 통지나 규제기관 보고가 필요한지도 판단해야 합니다. 이 결정은 지역, 데이터 유형, 접근 증거 및 적용 법률에 따라 달라집니다.

세 번째 신호는 향후 수개월 동안의 독립적인 재검증입니다. 연구자들은 유사한 스캔을 반복하고, 의도적으로 공개된 데이터와 민감한 노출을 구분하는 투명한 방법론을 공개해야 합니다.

데이터베이스 수가 감소한다면 Supabase의 더 안전한 기본 설정 전략을 뒷받침할 것입니다. 수치가 유지되거나 증가한다면, 플랫폼 성장과 AI 지원 개발이 기존 통제 장치가 바로잡을 수 있는 속도보다 더 빠르게 안전하지 않은 프로젝트를 만들어 내고 있음을 의미할 것입니다.

그 재검증 과정에서는 AI 코딩 제공업체도 면밀히 살펴봐야 합니다. 이들의 에이전트는 최소 권한 정책을 생성하고, 부정 권한 부여 테스트를 만들며, 배포가 개인정보를 노출할 때 경고해야 합니다.

개발자들이 책임감 있게 대응하기 위해 Supabase나 AI 코딩을 포기할 필요는 없습니다. 생성된 소프트웨어의 권한 부여 동작이 테스트되기 전까지는 신뢰할 수 없는 것으로 취급해야 합니다.

이는 익명 접근과 인증된 접근을 별도로 확인하고, 모든 데이터베이스 작업을 테스트하며, 뷰를 검토하고, 서버 키를 보호하며, 애플리케이션에 필요하지 않은 인터페이스를 비활성화하는 것을 의미합니다.

팀은 이러한 통제 조치의 근거가 된 결정도 보존해야 합니다. 검색 가능한 AI 지식 베이스는 문서화를 사후 과제로 전락시키지 않으면서 요구사항, 생성된 마이그레이션, 감사 결과 및 시정 조치 작업을 연결할 수 있습니다.

Supabase 데이터 노출 사례는 궁극적으로 책임성의 공백에 관한 이야기입니다. 플랫폼은 구성 가능한 통제 기능을 제공하고, AI 에이전트는 애플리케이션을 조립하며, 사용자는 완성된 인터페이스를 신뢰합니다.

실제 정보가 시스템에 들어가기 전에 보이지 않는 권한을 누가 검증할까요? AI가 생성한 앱을 출시하는 모든 조직은 테스트 결과, 지정된 책임자, 그리고 접근 거부에 대한 증거로 이 질문에 답할 수 있어야 합니다.