Firebase 브라우저 키 제한 미설정으로 13시간 만에 Gemini API 요금 €54,000 폭탄

• Firebase 프로젝트에 Firebase AI Logic을 활성화한 직후, Gemini API 사용량이 폭주해서 13시간 만에 €54,000 이상 과금됨

  • 원래 이 프로젝트는 1년 넘게 Firebase Authentication만 쓰고 있었음
  • 최근에 "텍스트 프롬프트로 웹 스니펫 생성"이라는 간단한 AI 기능을 추가하면서 Firebase AI Logic을 켰는데, 그 직후 터짐
  • 트래픽이 실제 사용자와 전혀 상관없는 패턴이었고, 자동화된 요청으로 보임 — 밤사이에 몰려왔다가 API 비활성화 + 크레덴셜 교체 후 멈춤

• 예산 알림이 있었는데도 속수무책이었음

  • €80짜리 예산 알림과 비용 이상 감지 알림 둘 다 설정해뒀지만, 수 시간 지연되어 트리거됨
  • 알림 받고 대응했을 때 이미 €28,000 상태
  • 비용 리포팅 지연 때문에 최종 금액은 €54,000+로 확정

• 핵심 문제는 브라우저에 노출된 Firebase API 키에 API 제한이 없었다는 것

  • Firebase 브라우저 키는 클라이언트 사이드에 노출될 수밖에 없는 구조인데, 여기에 Gemini API 접근 권한이 제한 없이 열려있었음
  • 공격자가 이 키를 긁어서 자동화된 Gemini API 호출을 대량으로 날린 것으로 추정
  • 글쓴이가 다른 개발자들에게 묻는 질문: App Check, 쿼터 설정, 서버사이드 호출 전환 외에 추가 방어책이 있는지

• 이 사례에서 얻을 수 있는 교훈이 명확함

  • Firebase/GCP 프로젝트에서 AI API를 활성화할 때는 반드시 API 키 제한을 먼저 걸어야 함
  • 예산 알림만으로는 부족함 — GCP 비용 리포팅이 실시간이 아니라 수 시간 딜레이가 있음
  • 클라이언트 사이드에서 직접 AI API를 호출하는 구조 자체가 위험 — 서버사이드 프록시를 거치는 게 안전
  • Google은 "프로젝트에서 나온 트래픽"이면 비정상이든 아니든 유효 사용으로 판단하는 경향이 있음

---

기술 맥락

• Firebase 브라우저 키가 위험한 이유를 좀 더 풀어볼게요. Firebase는 설계상 API 키가 클라이언트 코드에 포함되어야 해요. 웹 앱의 JS 번들이나 모바일 앱 바이너리에 들어가는 건데, 이건 사실상 "공개 키"나 마찬가지예요. 원래 Firebase Auth나 Firestore는 Security Rules로 접근을 통제하는 구조라 키 노출 자체는 괜찮았거든요
• 문제는 Gemini API 같은 과금형 서비스가 같은 키로 접근 가능해질 때 생겨요. Security Rules 같은 세분화된 접근 제어가 없고, API 호출 자체가 비용이니까요. API 키에 "이 키는 이 API만, 이 도메인에서만" 같은 제한(API restrictions)을 안 걸면 누구나 그 키로 Gemini를 무제한 호출할 수 있는 거예요
• GCP 빌링 알림의 지연도 중요한 포인트예요. GCP는 비용을 실시간으로 집계하지 않고 배치로 처리하거든요. 그래서 예산 알림을 €80으로 설정해도, 실제로 알림이 올 때는 이미 수천 유로를 넘긴 상태일 수 있어요. "하드 캡"이 아니라 "알림"일 뿐이라는 걸 인식해야 해요
• App Check는 이런 공격을 막는 Firebase의 공식 권장 방어선이에요. 앱이 정상적인 환경(진짜 브라우저, 진짜 앱)에서 실행되고 있는지 검증하는 어테스테이션(attestation) 토큰을 발급하는 방식인데요. 다만 완벽하지는 않고, 가장 확실한 건 AI API 호출을 서버사이드로 옮기는 거예요