Firebase API 키, 로그인 없이도 내 서버가 털릴 수 있는 이유
많은 개발자들이 "Firestore 규칙(Rules)이 있으니 API 키가 노출되어도 유저 정보는 안전하다"고 오해합니다. 해커가 데이터베이스에 접근하지 못하더라도 퍼블릭 키를 통해 발생할 수 있는 3가지 치명적 보안 위협과 이를 완벽히 방어하는 방법을 알아봅니다.
유저 데이터는 안전할 텐데, 왜 위험할까?
프론트엔드 코드에 포함된 `NEXT_PUBLIC_FIREBASE_API_KEY`는 누구나 브라우저 개발자 도구에서 쉽게 확인할 수 있습니다. 많은 사람들이 "어차피 Firestore 데이터베이스는 로그인한 유저만 읽고 쓰게 Rules를 짰으니까 키가 털려도 상관없다"고 생각합니다.
네, 데이터가 당장 유출되지는 않습니다. 하지만 해커는 로그인 없이도 다음과 같은 치명적인 피해를 입힐 수 있습니다.
치명적 위협 1: 요금 폭탄 (Billing Attack)
무제한 봇 공격
해커가 스크립트를 짜서 우리 프로젝트의 API 키로 수만 번의 무의미한 로그인 요청을 보내거나, 존재하지 않는 데이터에 무한정 읽기 요청을 보냅니다.
데이터 접근은 거부되더라도 "요청" 자체는 서버에 도달합니다. 특히 전화번호 인증(SMS)을 사용 중이라면 해커가 무단으로 수만 건의 인증 문자를 발송하게 만들어 하룻밤 새에 수백만 원의 요금 폭탄을 맞을 수 있습니다.
치명적 위협 2: 피싱 사이트 (Phishing)
해커가 우리 사이트와 완벽하게 똑같이 생긴 가짜 웹사이트(예: hacker.com)를 만듭니다. 그리고 훔쳐낸 우리 프로젝트의 Firebase API 키를 심어둡니다.
사용자가 가짜 사이트에서 속아서 로그인을 시도하면, 실제 우리 프로젝트에 로그인이 진행됩니다. 해커는 중간에서 사용자의 입력값을 가로채거나, 사용자를 안심시킨 후 추가적인 금전적 사기를 칠 수 있습니다.
치명적 위협 3: 테스트 모드 방치
"allow read, write: if true;"
가끔 개발 편의를 위해 임시로 DB 보안 규칙을 누구나 접근 가능하게 열어두는 실수를 할 때가 있습니다. 이 틈을 타 해커가 DB를 통째로 지워버리거나 랜섬웨어를 심을 수 있습니다.
완벽한 방어책: 도메인 제한 설정 (HTTP 리퍼러)
API 키가 노출되어도, 오직 "우리가 허락한 도메인"에서 온 요청만 구글 서버가 받아주도록 설정해야 합니다.
1. Google Cloud Console(사용자 인증 정보)에 접속합니다. 2. 프로젝트를 선택하고 API 키 설정으로 들어갑니다. 3. "애플리케이션 제한사항"에서 "HTTP 리퍼러(웹사이트)"를 선택합니다. 4. 내 웹사이트 도메인(예: https://example.com/*)과 로컬 테스트용(http://localhost:*)을 등록하고 저장합니다.
설정 완료
이제 해커가 자기 컴퓨터(hacker.com)에서 요청을 보내면 구글 서버가 403 Forbidden 에러를 반환하며 원천 차단합니다!
내 프로젝트는 과연 안전할까?
Firebase 외에도 AWS, Supabase, 각종 결제 PG사 연동 시 이런 사소한 설정 누락으로 큰 사고가 발생합니다.
위 링크의 보안 점검 위자드를 통해 터미널 스캐너와 AI 감사를 돌려보세요. 생각지도 못했던 취약점을 클릭 한 번으로 찾아냅니다.
이정마 에디터
Security Analyst
NEXT_PUBLIC_ 변수는 브라우저로 그대로 전송되므로 절대 비밀번호나 시크릿 키를 넣어서는 안 됩니다. 하지만 Firebase API 키처럼 불가피하게 공개되어야 하는 키라도 최소한의 도메인 안전장치는 필수입니다.