feat: Firebase 보안 강화 및 백업 설정

[giljihun]

곧 정식 배포를 앞 둔 상태에서, 우리팀 DB (파이어베이스)의 대대적인 점검 시간을 가졌다.
왜냐면, 요금폭탄과 해킹으로부터 헤븐의 지갑(ㅋㅋ)을 지키기 위해 왔다.

왜 이 작업이 필요한가요?

우리 앱, 해킹당할 수 있어요

앱에 "삭제 버튼"이 없어도 해커는 데이터를 조작할 수 있습니다.

가볍게 보는 해커가 우리앱 공격하는 방법

1. 앱을 분석해서 Firebase 서버 정보를 추출
2. 직접 API를 호출하거나
3. 프록시 툴(Charles, Burp Suite)로 앱과 서버 사이의 통신을 가로채서 조작

예시 시나리오

1. 해커가 자기 키링을 삭제하는 요청을 보냄
2. 중간에 가로채서 "내 키링 ID"를 "다른 유저 키링 ID"로 변경
3. 서버는 그대로 실행 → 다른 유저 키링 삭제됨
😱😱😱 호러쇼 시작 

이게 왜 가능했냐고?

• 파이어베이스 보안룰이 모두에게 오픈된 ㄹㅇ public 상태였음.
• 깃헙이 public이라 코드를 보면 api 호출 쿼리를 어느정도 짐작가능함. (엄청 크리티컬 하진 않음.)
• 해커들은 우리앱을 안써도 우리 파이어베이스 디비는 건드릴 수 있음.

다른 사람 키링, 유저, 데이터 모두 삭제 버튼 따위 우리 앱엔 없지만 가능함.

이런 공격을 막기 위해 3가지 보안 설정을 추가했습니다.

추가한 보안 설정

1. Firebase 일일 백업 설정 (Daily Backup)

• 매일 자동으로 Firestore 데이터를 백업합니다.
• 만약 해킹이나 실수로 데이터가 삭제되어도 복구가능.

기존엔 30일마다 자동백업이라고 한다.

• 보관 기간: 30일로 설정(Google Cloud Storage에 저장됨)
• 저장 용량 기준 과금 (GB당 월 $0.026 정도)
• 우리 앱 데이터 규모면 월 몇백원 수준 (아마 그럴거야)

저 위에 보이는 PITR은 리얼 분단위 순간으로 백업하는 기능이라는데,
현실적으로 아직 불필요해보여서 적용하지 않았음.

2. Firebase Security Rules 설정

설정 전, 기존 룰인데 제미나이 말하는거 개웃김 ㅋㅋ

이 데이터는 누가 읽고/쓸 수 있는가"를 서버에서 검증하는 기능

이전 상태는 로그인만 하면 모든 데이터 접근 가능했음.

allow read, write: if request.auth != null;
→ 해커가 로그인만 하면 다른 유저 데이터도 삭제/수정 가능

변경 후엔, 우리 앱 크리티컬한 데이터에 대한 authorId 체크 + 아래 나오는 AppCheck 로직으로 이중 검수함.

자세한 코드는 올리지 않겠음.

3. Firebase App Check + Apple DeviceCheck 설정(오늘의 ACE)

"이 요청이 진짜 우리 앱에서 온 건가?"를 검증합니다.
여기서 말하는 진짜 우리 앱이란, 앱스토어에 정식 등록된 앱을 말함.

그러니까,
해커들은 우리 앱과 DB를 해킹하려고 할 때 Rules의 조건때문에
무조건 우리앱 로그인이 필요함.

그런데,
해커들은 우리 앱 안써도 다른 프로그램 돌려서 로그인할 수가 있단말이야.

그런 말도안되는 경우를 막아주는게 Firebase App Check + Apple DeviceCheck 설정이다 이거야.

쉽게 말해서, 막 스크립트/매크로 돌려서 우리앱 자동접속 -> api 계속호출 -> 요금 폭탄!
이런거 당할 수가 없음.

설정 내용

• 프로덕션: DeviceCheck Provider (실기기는 자동 검증)
• 디버그: Debug Provider (디버그모드에선 개발용 토큰을 파이어베이스에 등록해야함!)

// AppDelegate.swift
#if DEBUG
let providerFactory = AppCheckDebugProviderFactory()
#else
let providerFactory = DeviceCheckProviderFactory()
#endif
AppCheck.setAppCheckProviderFactory(providerFactory)

FirebaseApp.configure()

이제부터, 우리의 각자 폰에서 빌드하려면 이 디버그 코드도 등록을 해야함.
위에서 말했듯이, 실제 정식 앱스토어 기준의 등록앱이면 상관없음.

이런식으로 디버그 모드에서 디바이스 실행해보면 디버그 토큰이 나옴.

실제 인가받지않은 기기면, 이렇게 403 에러가 등장한다.

파이어베이스에서 인가받지 않은 요청에 대해 모니터링도 된다.

주의 사항

Firebase App Check + Apple DeviceCheck은 지금 당장 적용해버리면
모든 사용자가 앱을 사용할 수 없게됨.
현재 해당 코드가 배포되지 않았기 때문에.

그래서 배포 이후 시간을 갖은 후에, 적용할 예정임.

거의 진격의 거인 월시나

다시 우리 앱 방어 구조 한눈에 먼저 보고 마무리하자.

방어층	역할	막는 공격
App Check	앱 무결성 확인 (진짜 앱인가?)	가짜 앱, 외부 스크립트, 데이터 크롤링
Auth	사용자 신원 확인 (누구인가?)	비로그인 사용자의 무단 데이터 접근
Rules	리소스 권한 제어 (권한이 있는가?)	타인의 데이터 수정 및 불법 열람 시도

🔗 관련 이슈

• Feature: App Check 보안 계층 도입 및 SDK 설정 #65

✅ 체크리스트

• 빌드 성공
• 테스트 완료
• Self-review 완료

[jini-coding]

오 말로만 얘기했던 부분도 다 정리를 해주셨네요. 정말 필요했던 보안 강화였습니다.
앱체크는 디벨로퍼 계정에서도 설정을 해줘야하군요. 이런 기능이 있는줄 요번 기회에 알고 갑니다!

[freshfresh22]

╭ ◜◝ ͡ ◜◝ ͡ ◜◝ ͡ ◜◝ ͡ ◜◝ ╮
♡ 403 백지를 내도 백점 ♡
♡ 403 NEw era era ♡
╰ ◟◞ ͜ ◟ ͜ ◟◞ ͜ ◟ ͜ ◟◞ ╯
⠀⠀⠀⠀O
⠀⠀⠀⠀⠀°
〃o　 (\＿(
‎⊂⌒（ ´ • ﻌ •）
ヽ_っ＿/￣￣￣/
　 　 ＼/＿＿＿/