앱 개발 외주할 때 Firebase 보안 설정, 왜 자꾸 구멍이 생기나 (kasra.blog)

한줄 요약

API 보안은 챙겼는데 Firebase 접근 제어를 빠뜨리는 건 앱 개발 외주 현장에서 가장 흔한 취약점 패턴 중 하나다.

---

최근 보안 연구자들 사이에서 LLM(대형 언어 모델)을 활용해 실제 앱의 취약점을 자동으로 찾아내는 실험이 활발하게 진행되고 있다. 한 연구에서 의도적으로 취약하게 만든 모바일 앱을 여러 LLM에 분석시킨 결과, 일부 모델은 실제로 Firebase 인증을 우회하고 비공개 데이터를 추출하는 데 성공했다. 이 실험이 외주 개발사 입장에서 중요한 이유는 하나다. 해당 취약점이 실험실에서 만든 가상 시나리오가 아니라, 실제 서비스 운영 중인 앱에서 반복적으로 발견되는 패턴이기 때문이다.

Firebase를 데이터 레이어로 쓸 때 무슨 일이 벌어지나

많은 앱 개발 프로젝트에서 백엔드 API는 인증, 권한 검증, 입력값 필터링을 꼼꼼하게 구현한다. 그런데 Firebase나 Supabase 같은 BaaS(Backend as a Service)를 데이터 레이어로 함께 사용할 때, API 보안과 BaaS 접근 제어를 별개로 관리하다 보면 틈이 생긴다.

문제의 구조는 이렇다. 앱 클라이언트 안에는 Firebase 프로젝트 연결 정보가 담긴 설정 파일이 포함된다. 이 파일은 앱이 동작하기 위해 반드시 필요하고, APK나 IPA를 추출하면 누구나 꺼낼 수 있다. 설정 파일 자체가 비밀키는 아니지만, Firebase 인증 규칙이 느슨하게 설정돼 있으면 이 정보만으로도 직접 회원가입하고 Firestore 데이터에 접근하는 것이 가능해진다. API 서버를 전혀 거치지 않고.

LLM 실험에서 성공한 모델들이 공통적으로 한 행동이 바로 이것이다. API 엔드포인트를 공략하는 대신, 앱 바이너리에서 Firebase 설정을 꺼내 Firebase SDK로 직접 인증을 시도하는 방식으로 전환했다.

외주 개발 현장에서 이 취약점이 반복되는 이유

앱 개발 업체 입장에서 이 문제가 구조적으로 발생하는 데는 몇 가지 이유가 있다.

첫째, 역할 분리다. API 개발팀과 Firebase 설정을 담당하는 팀이 다를 때, 서로 상대방이 보안을 챙긴다고 가정하는 경우가 생긴다. API 쪽은 자기 레이어를 잘 막았으니 됐다고 생각하고, Firebase 룰셋은 개발 편의를 위해 열어둔 채로 배포까지 가는 경우다.

둘째, 납기 압박이다. Firebase Security Rules를 제대로 작성하고 테스트하는 데는 시간이 필요하다. 스프린트 막판에 "일단 배포하고 나중에 조이자"는 판단이 내려지면, 그 '나중'이 오지 않는 일이 많다.

셋째, 테스트 범위 문제다. QA에서 기능 테스트와 API 테스트는 챙기더라도, Firebase에 SDK로 직접 붙어보는 시나리오는 테스트 케이스에 없는 경우가 대부분이다. 공격자의 시각이 아닌 사용자의 시각으로만 테스트를 설계하면 이런 경로는 보이지 않는다.

LLM이 찾아낸 취약점이 우리에게 주는 신호

이번 실험에서 흥미로운 건 모델 간 성능 차이만이 아니다. 실제로 취약점을 찾아낸 모델들이 사용한 방법론이 고도로 정교하지 않았다는 점이다. 설정 파일 추출, Firebase 직접 인증 시도, 데이터 접근 확인. 이 세 단계로 끝난다.

바꿔 말하면, 이 정도 자동화된 접근만으로도 뚫린다는 뜻이다. 악의적인 사용자가 수작업으로 이걸 찾아내는 데 걸리는 시간은 더 짧을 수도 있다. LLM 실험은 "이미 알려진 공격 패턴"이 얼마나 빠르게 자동화되고 있는지를 보여주는 지표다.

앱 개발 외주를 맡기는 클라이언트 입장에서도 이 실험은 질문 하나를 던지게 한다. 우리 앱은 API 보안만 챙겼나, 아니면 데이터 레이어 접근 제어까지 검토했나?

외주 개발사가 실제로 해야 할 것

취약점 클래스 이름은 Broken Access Control 또는 Object-Level Authorization 누락으로 불린다. 예방법은 개념적으로 단순하지만 실행이 빠져 있는 경우가 많다.

Firebase를 사용하는 프로젝트라면 Security Rules를 배포 전 필수 체크리스트 항목으로 올려야 한다. "인증된 사용자는 자신의 데이터만 읽고 쓸 수 있다"는 원칙을 Rules 파일에 명시적으로 구현했는지 확인해야 한다. Supabase라면 Row Level Security(RLS) 정책이 활성화돼 있는지 봐야 한다.

추가로, 모바일 앱 배포 전에는 역공학 시나리오를 한 번 돌려보는 것이 좋다. APK를 디컴파일했을 때 외부에 노출돼서는 안 되는 정보가 하드코딩돼 있지 않은지, 꺼낸 설정 정보로 서비스에 직접 붙을 수 있는 경로가 있는지를 확인하는 작업이다. 이건 별도의 보안 감사 없이도 개발팀 내부에서 체크리스트로 관리할 수 있다.