Lovable / Bolt / Replit 앱이 사용자의 데이터를 유출하고 있는지 확인하는 5분 가이드, 그리고 왜 유출될 가능성이 높은지에 대하여.

저는 Lovable, Bolt, Replit, Cursor와 같은 AI 도구로 구축된 앱들을 수정해 왔으며, 거의 모든 앱에서 동일한 몇 가지 심각한 보안 결함이 나타납니다. 이는 창업자들이 무언가 잘못했기 때문이 아니라, 도구들이 "사용자의 데이터를 안전하게 보호하기"보다는 "데모를 작동시키기"에 최적화되어 있기 때문입니다.

제 의도를 보여드리기 위해, 저는 기술적 지식이 없는 창업자가 하는 방식 그대로 작은 작업 관리자(task manager)를 구축했습니다. AI에게 설명하고, 데이터베이스와 로그인을 위해 Supabase를 연결하고, 배포했습니다. 표준 스택(stack)과 표준 프롬프트(prompt)를 사용했습니다. 그 후 보안 점검을 실시했습니다.

제가 직접 코드를 작성하기도 전에, 5개의 심각한 문제와 추가로 3개의 문제가 발견되었습니다.

그리고 이것은 단지 저의 데모 앱만의 문제가 아닙니다. Escape.tech가 이런 방식으로 구축된 5,600개의 실제 운영(production) 앱을 스캔했을 때, 1,400개에서 취약점이 발견되었고 400개 이상의 유출된 비밀 정보(secrets)를 찾아냈습니다. 200개 이상의 앱을 대상으로 한 별도의 감사(audit)에서는 91.5%가 최소 하나 이상의 AI 생성 보안 결함을 가지고 있다는 사실이 밝혀졌습니다. 이것은 예외가 아니라 일반적인 현상입니다.

제 앱에서 무엇이 잘못되었는지, 그리고 여러분의 앱에서도 정확히 어떻게 동일한 사항들을 확인할 수 있는지 알려드리겠습니다. 대부분은 1분 정도 걸리며 브라우저만 있으면 됩니다.

1. 브라우저를 사용하는 누구라도 데이터베이스를 읽을 수 있었음

이것은 가장 큰 문제이며, 어디에나 존재합니다. Supabase는 기본적으로 행 수준 보안(Row-Level Security, RLS)이 꺼진(off) 상태로 새 테이블을 제공합니다. 이는 여러분의 앱 프론트엔드(frontend)에 위치하여 모든 방문자의 브라우저가 다운로드하는 공개 키(public key)가 모든 테이블의 모든 행을 읽을 수 있음을 의미합니다. 제 앱의 경우, 여기에는 모든 사용자의 이메일과 비밀번호가 포함되어 있었습니다.

확인 방법: 기술적 지식이 있다면, Supabase 대시보드를 열어 테이블에 RLS가 활성화되어 있는지, 그리고 정책(policies)이 실제로 로그인한 사용자에게만 행의 범위를 제한하고 있는지 확인하십시오. 기술적 지식이 없다면, 이 사항은 누군가에게 반드시 확인을 요청해야 할 가장 중요한 사항입니다.

2. 관리자 키(admin key)가 브라우저로 전송됨

권한 오류를 "해결"하기 위해, AI 도구들은 때때로 service_role 키를 프론트엔드 (frontend)에 그대로 떨어뜨려 놓습니다. 해당 키는 모든 보안 규칙을 우회합니다. 개발자 도구 (developer tools)를 열고 페이지 소스 (page source)를 보는 사람이라면 누구나 이를 찾아내어 데이터베이스 (database)에 대한 완전한 제어권을 가질 수 있습니다.

확인 방법: 실제 운영 중인 사이트를 열고, 마우스 오른쪽 버튼을 클릭하여 [페이지 소스 보기]를 선택한 뒤, 로드된 .js 파일들을 확인하세요. 텍스트에서 service_role을 검색해 보세요. 만약 발견된다면, 그것은 매우 심각한 비상 상황입니다. 즉시 해당 키를 교체(rotate)하십시오.

3. 서드파티 (Third-party) API 키가 프론트엔드에 노출되어 있음

제 앱은 OpenAI 키가 브라우저 번들 (browser bundle)에 노출되어 있었습니다. 누구나 그런 키를 탈취하여 귀하의 계정으로 수천 달러의 비용을 발생시킬 수 있습니다.

확인 방법: 동일한 페이지 소스에서 sk-, sk_live_, 또는 AIza를 검색해 보세요. 이것들은 OpenAI, Stripe, 그리고 Google 키의 접두사 (prefix)입니다. 이 중 그 어떤 것도 프론트엔드에서 보여서는 안 됩니다.

4. 관리자 패널이 보호된 것이 아니라 단순히 "숨겨져" 있었음

앱은 단 한 줄의 JavaScript 코드를 통해 브라우저 내에서 사용자가 관리자인지 확인했습니다. 하지만 서버 (server)에서는 그러한 확인 절차를 전혀 수행하지 않았습니다. 누구나 개발자 도구를 열어 해당 플래그 (flag)를 바꾸기만 하면 관리자 화면으로 곧장 진입할 수 있습니다. 동일한 패턴을 통해 일반 사용자가 URL의 ID를 변경하는 것만으로 다른 사용자의 데이터를 읽을 수도 있습니다.

확인 방법: 이 항목은 개발자의 확인이 필요하지만, 징후는 간단합니다. 서버가 아닌 인터페이스 (interface)에만 존재하는 보호 조치(숨겨진 버튼, isAdmin 플래그 등)는 보호라고 할 수 없습니다.

5. 속도 제한(rate limiting), 보안 헤더(security headers), 테스트 부재

비밀번호 재설정 엔드포인트 (endpoint)는 아무런 제어 장치 없이 초당 수천 번씩 호출될 수 있었습니다. 앱은 브라우저가 찾는 표준 보안 헤더 (security headers)를 전혀 보내지 않았습니다. 또한 자동화된 테스트 (automated test)가 단 하나도 없었는데, 이는 모든 "빠른 수정"이 기존에 잘 작동하던 무언가를 소리 없이 망가뜨릴 위험이 있음을 의미합니다.

확인 방법: securityheaders.com에서 몇 초 안에 귀하의 헤더를 무료로 등급 매길 수 있습니다.

왜 이런 일이 계속 발생하는가

이 모든 것이 AI 빌더(AI builders)나 이를 사용하는 사람들을 비난하려는 의도는 아닙니다. 이 도구들은 아이디어를 작동하는 프로토타입(prototype)으로 만드는 데 있어 진정으로 놀라운 능력을 보여줍니다. 하지만 이들은 모든 것이 제대로 돌아가고 아무도 침입을 시도하지 않는 버전인 '해피 패스(happy path)'를 생성합니다. 보안(Security), 권한(permissions), 그리고 에러 핸들링(error handling)은 지속적으로 건너뛰게 되는 보이지 않는 20%입니다. 왜냐하면 당신이 그것들을 요청하지 않았고, 데모(demo)는 그것들 없이도 잘 작동하기 때문입니다.

문제는 "데모가 작동한다"는 것과 "실제 사용자를 배치해도 안전하다"는 것은 매우 다른 기준이며, 그 사이의 간극이 바로 데이터 유출(data leaks)이 발생하는 지점이라는 것입니다.

도움이 필요하다면

이 글을 읽고 본인의 앱에 대해 불안한 느낌이 들었다면, 그 직감이 보통 맞습니다.

귀하의 앱 URL을 이메일로 보내주시면 무료로 안전하게 스캔해 드리겠습니다. 저는 귀하의 앱이 이미 대중에게 공개하고 있는 정보만을 확인하며(로그인, 데이터베이스 접근, 침해적인 행위 없음), 외부에서 무엇이 보이는지 알려드립니다: mike@mriheanacho0.com.

전체적인 그림을 보고 싶다면, 유료 진단 서비스를 제공합니다. 귀하의 앱과 코드를 검토하여 위와 같은 모든 문제를 찾아내고, 심각도에 따라 순위를 매긴 뒤, 각 문제에 대한 수정 예상 비용이 포함된 서면 보고서를 제공합니다. 제가 수정을 진행하든 하지 않든 이 보고서는 귀하의 소유입니다. 수정 사항은 귀하가 검토하고 병합(merge)할 수 있도록 풀 리퀘스트(pull request) 형태로 전달되며, 귀하의 허락 없이는 절대 운영 환경(production)을 건드리지 않습니다.

어떤 방식이든, 이 다섯 가지를 확인해 보십시오. 귀하의 사용자들은 자신의 데이터를 귀하에게 믿고 맡기고 있으며, 현재 그 데이터가 무방비하게 노출되어 있을 가능성이 높습니다.

Mike I., mike@mriheanacho0.com