
여성 안전 앱에서 13,000개의 정부 신분증 유출
요약
여성 안전 앱 Tea의 Firebase 데이터베이스가 보안 설정 없이 방치되어 13,000개의 정부 신분증을 포함한 대규모 개인정보가 유출되었습니다. 이번 사고는 액세스 제어(Access Control)가 없는 공개 데이터베이스 설정이라는 고전적인 보안 실수를 보여줍니다.
핵심 포인트
- Firebase 테스트 모드의 허용적인 규칙 설정이 보안 취약점으로 작용
- 인증 및 액세스 제어 계층 부재로 인한 대규모 데이터 유출 발생
- AI 생성 코드가 보안 실수를 가속화할 수 있으나, 근본 원인은 관리 부실
- 제품 출시 전 반드시 보안 강화 및 액세스 제어 검토 필요
전체 연구 및 플러그인 → github.com/bcanfield/agentic-tech-debt
Tea의 백엔드인 Firebase 데이터베이스가 지난 7월 인터넷에 공개된 상태로 방치되어 있었으며, URL을 찾은 사람이라면 누구나 그 내용을 모두 읽을 수 있었습니다. 약 72,000개의 이미지, 그중 약 13,000개는 정부 신분증(government IDs)이었습니다. 즉, 운전면허증과 사용자들이 여성임을 증명하기 위해 업로드한 셀카였습니다. Tea는 데이트 전 남성을 검증하기 위한 여성 전용 앱이기 때문입니다. 그 외에도 110만 개 이상의 개인 메시지가 포함되어 있었습니다. 비밀번호도, 인증(auth) 확인도, 토큰(token)도 없었습니다. 그저 스크립트를 겨냥할 수 있는 버킷(bucket)일 뿐이었습니다.
신분증이 존재했던 이유는 남성을 차단하기 위해 앱이 신원 증명을 요구했기 때문입니다. 그러고 나서 그 증명 자료를 4chan의 남성이 오후 한나절 만에 통째로 긁어갈 수 있는 어딘가에 저장해 두었습니다. 사용자를 보호하기 위해 만들어진 것이 오히려 사용자의 신상을 노출(doxxed)하는 도구가 된 것입니다.
나머지 내용을 다루기 전 한 가지 주의할 점이 있습니다. 널리 퍼진 원인 분석(이것이 보안 검토 없이 배포된 AI 생성 코드인 "바이브 코딩(vibe coding)"이었다는 주장)은 원본 4chan 게시자로부터 나온 것이며, 여러 보도 매체에서 이를 인용했습니다. 저는 Tea 측에서 코드가 어떻게 작성되었는지 확인하는 것을 보지 못했으므로, "AI가 했다"는 말을 기정사실로 받아들이지는 마십시오. 확실한 것은 실패의 형태이며, 그 형태를 설명하는 데 AI가 꼭 필요하지는 않습니다. 액세스 제어(access control)가 없는 공개 데이터베이스는 가장 오래된 실수 중 하나입니다. AI는 단지 그 실수를 더 빠르고 조용하게 저지르게 만들 뿐입니다.
따라서 원인 규명은 제쳐두고 메커니즘을 살펴보겠습니다. Firebase 데이터베이스에는 누가 무엇을 읽을 수 있는지 결정하는 계층인 규칙(rules)이 있습니다. Firestore 데이터베이스를 테스트 모드(test mode)로 실행하면, 30일 후에 만료된다는 경고 배너와 함께 가장 허용 범위가 넓은 규칙을 작성해 줍니다:
// Firestore 테스트 모드: 새 데이터베이스가 기본적으로 제공하는 설정
allow read, write: if true;
이것은 의도적으로 허용적인 설정입니다. 인증 계층(auth layer)과 먼저 싸우지 않고도 개발을 진행할 수 있도록 말이죠. 보안을 강화하는 것은 제품을 출시(ship)하기 전에 수행해야 하는 별도의 단계입니다. "이게 작동하게 만들자"와 "실제 사용자의 운전면허증이 들어있는 상태로 라이브 서비스 중이다" 사이의 어느 지점에서, 그 단계가 수행되지 않았습니다. 저는 이것이 어떤 종류의 실패인지 정확히 짚고 넘어가고 싶습니다. 왜냐하면 "데이터베이스 보안 설정을 잊어버렸다"라고 말하면 마치 단순한 실수처럼 들리기 때문입니다. 보안을 강화하는 것은 실제적인 작업입니다. 규칙(rules)을 작성하고, 인증되지 않은 요청이 실제로 거부되는지 테스트하며, 로그인한 한 사용자가 다른 사용자의 기록을 읽을 수 없는지 확인해야 합니다. 반나절 정도면 되는 일이죠. 데드라인이 임박하고 앱이 이미 데모에서 작동하고 있는 상황이라면, 그 반나절의 작업은 "출시 전"으로 미루기가 세상에서 가장 쉬운 일이며, 그다음엔 "출시 직후"로, 결국에는 누구의 기억 속에서도 사라지게 됩니다. 그래서 저는 이 열려 있는 데이터베이스를 사고라고 읽지 않습니다. 저는 이것을 "나중에 보안을 강화하자"라는, 기본값으로 내려졌으나 아무런 계기가 없어 다시 검토되지 않은 하나의 결정으로 읽습니다.
저 또한 그 결정의 작은 버전을 내린 적이 있습니다. 반복적인 개발(iterate)을 할 수 있도록 규칙을 완전히 개방한 채 개발용 백엔드(dev backend)를 가동하고, 실제 사용자가 접근하기 전에 규칙을 강화하겠다고 스스로 다짐하는 것이죠. 그때 "의도적으로 개방함, 나중에 수정할 것"이라는 유일한 기록은 화요일에 스치듯 지나간 생각뿐입니다. 저는 제 것을 제때 강화했지만, 그것은 규율 덕분이 아니었습니다. Tea가 저지른 것과 동일한 과실이었지만, 저는 열려 있는 규칙 뒤에 13,000개의 운전면허증을 방치해 두지는 않았을 뿐입니다.
이러한 이야기들을 관통하는 핵심이며, Tea(티)는 그 사례 중 가장 전형적입니다. 피해의 원인은 잘못된 코드 한 줄에서 비롯된 것이 아닙니다. 아무도 기록하지 않은 '미루기(deferral)'에서 비롯되었습니다.
이것이 바로 제가 debt-ops를 통해 구축하고자 했던 것입니다. 이 도구는 코딩 에이전트 (coding agent)에 연결되어, 에이전트의 "데이터베이스 프로비저닝됨 (database provisioned)" 요약에는 절대 언급되지 않는 각 미루어진 결정 사항들을 마크다운 (markdown) 파일에 기록합니다. 이를 통해 _지금은 인증 (auth)을 꺼두기로 함_과 같은 선택 사항이 출시 전에 사람이 찾아낼 수 있는 어딘가에 남게 됩니다. 해당 저장소 (repo)는 github.com/bcanfield/agentic-tech-debt입니다. 한계점을 명확히 하자면, 이 도구는 보안 규칙을 작성하지 않으며, 허용적인 기본값 (permissive default)과 의도적인 기본값을 구분할 수 없습니다. 이 도구가 하는 일은 단지 침묵 속에서 이루어진 선택을, 아예 보지 못하는 대신 당신이 의도적으로 읽고 기각해야 하는 텍스트 한 줄로 바꾸는 것뿐입니다.
커버 사진: Unsplash의 Michael Chacon.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기
