Lovable이 800만 유저 데이터를 48일간 노출한 동안 — 바이브코더가 5분 안에 해야 할 자기 점검
핵심 요약 (TL;DR)
Lovable에서 BOLA(객체 권한 누락) 취약점이 터져 800만 사용자의 소스코드, Supabase DB 자격증명, AI 채팅 히스토리, Stripe 고객 ID까지 48일간 무료 계정의 API 5번 호출만으로 조회 가능했습니다. 회사는 처음에 "데이터 유출이 아니라 의도된 동작"이라고 답했고요. 핵심은 BaaS 키를 클라이언트에 박은 모든 바이브코딩 앱이 같은 위험을 안고 있다는 점입니다.
800만 사용자가 5번의 API 호출 앞에 무방비였다는 뜻
익명의 보안 연구원이 3월 3일 HackerOne으로 한 줄짜리 제보를 올렸습니다. "무료 계정 만들고 API 5번 호출하면 다른 사용자의 프로젝트가 다 보입니다." Lovable은 "중복 제보"라며 종결 처리했고, 그 후 48일 동안 아무도 손대지 않았습니다. 연구원이 4월 20일 폭로하자 회사는 2시간 만에 핫픽스를 배포했습니다(TheNextWeb 보도).
노출된 정보의 결은 가볍지 않습니다. 사용자 프로필, 소스코드, Supabase 데이터베이스 자격증명, AI와 나눈 채팅 히스토리, Stripe 고객 ID. NVIDIA·Microsoft·Uber·Spotify 직원으로 추정되는 계정의 사용자 데이터까지 조회 가능했다는 게 연구원 측 주장입니다(회사 공식 확인은 없는 상태).
더 묘한 건 Lovable의 첫 반응이었습니다. "데이터 유출이 아니다, 의도된 동작이다." 그다음엔 "문서가 불명확했던 우리 잘못", 또 그다음엔 HackerOne 탓. 부분 사과까지 가는 데 며칠이 걸렸습니다(Lovable 공식 블로그).
BOLA가 뭐길래 — "권한 검사를 빠뜨린 것"의 진짜 의미
BOLA(Broken Object Level Authorization)는 화려한 이름과 달리 본질이 단순합니다. "이 사용자가 이 객체를 볼 권한이 있나?"를 서버가 확인하지 않는 상태죠. URL의 ID만 바꾸면 남의 데이터가 그냥 응답에 실려 옵니다.
Lovable의 경우 더 결정적이었던 건 사용자가 자기 앱에 하드코딩한 Supabase·Stripe 키가 함께 노출됐다는 점입니다. 키 하나면 그 앱의 백엔드 자체가 통째로 열립니다. 바이브코딩 도구의 "5분 만에 풀스택 앱" 약속이 그대로 "5분 만에 데이터베이스 통째 유출"이 되는 구조예요.
내 앱은 안전한가 — 5분 점검 체크리스트
1. 클라이언트 코드에 시크릿 키가 박혀 있나? Supabase의 service_role 키, Stripe의 sk_live 키, Firebase admin 키. 브라우저에서 보이는 자리(JS 번들, .env.local 노출 폴더)에 있다면 즉시 빼야 합니다. anon 키만 클라이언트에 두는 게 원칙입니다.
2. RLS(Row Level Security)가 켜져 있나? Supabase는 기본값이 RLS off입니다. 테이블별로 "이 행을 누가 읽고 쓸 수 있는지" 정책을 명시하지 않으면, 한 사용자의 토큰으로 전체 테이블을 긁을 수 있습니다.
3. API 엔드포인트마다 "이 객체가 이 사용자 거 맞나?" 검사가 있나? GET /api/projects/:id에서 :id만 1, 2, 3으로 바꿔 보세요. 401이 떨어져야 정상이고, 200이 떨어지면 BOLA입니다.
4. 키가 이미 노출됐다면 즉시 로테이션. 한 번 인터넷에 나간 키는 다시 비밀이 될 수 없습니다. 시크릿 매니저(Vercel Env, Doppler, AWS Secrets Manager)로 옮기고 옛 키는 폐기하세요.
5. 모니터링 한 줄 추가. Supabase 대시보드의 비정상 쿼리 패턴, Stripe의 비정상 API 호출 알림. 켜져 있는지 확인만이라도.
바이브코딩의 진짜 비용은 "안 보이는 보안 부채"
Lovable·Replit·Cursor 같은 도구는 "코드를 안 봐도 동작한다"는 게 매력입니다. 그런데 안 보이는 게 곧 검토되지 않았다는 뜻이에요. 인증·권한·키 관리는 AI가 "기본값으로 잘 깔아두지" 않습니다. 잘 동작하는 것처럼 보이는 앱과 보안적으로 안전한 앱 사이의 거리는 생각보다 멉니다.
Lovable이 48일 동안 입을 다문 동안, 같은 코드 패턴을 쓰는 모든 앱이 같은 위험을 공유하고 있었습니다. 도구를 탓하기 전에 내 앱부터 5분 점검을 권합니다.
자주 묻는 질문
Q. RLS만 켜면 안전한가요?
출발선일 뿐입니다. 정책을 잘못 짜면 RLS가 켜져 있어도 다 뚫립니다. "인증된 사용자면 모두 read" 같은 정책은 실질적으로 RLS off와 같습니다. auth.uid() = user_id 같은 객체 단위 조건이 들어가야 의미가 있습니다.
Q. Lovable로 만든 앱을 통째로 폐기해야 하나요?
그럴 필요는 없습니다. 핫픽스가 적용됐고, 위 체크리스트를 통과하면 위험은 일반 SaaS 수준입니다. 다만 사고 이전에 노출됐을 가능성이 있는 키는 무조건 로테이션하세요.
Q. 비개발자인데 어디서부터 손대야 하나요?
Supabase 대시보드 → Authentication → Policies 탭만 먼저 열어 보세요. 정책 0개인 테이블이 있다면 거기가 가장 위험합니다. AI에 "이 테이블에 사용자가 자기 데이터만 읽고 쓸 수 있는 RLS 정책 만들어줘"라고 물어보면 출발 가능합니다.
댓글 0
아직 댓글이 없습니다