🤔 Firebase API Key를 공개하는 것이 안전합니까?

📌 고민하게 된 계기

• 스터디 모집 개인 프로젝트를 진행하면서 백앤드로 firebase를 사용하게 되었습니다.
• 사용하면서 API Key이니까 당연히 .env 파일로 관리해야지라고 생각한 뒤 관리를 하게 되었고, 그 후 Ci/Cd를 위해 Github-Action 사용하고 있었고 CI를 진행하면서 .env파일로 인해 테스트가 깨지는 현상이 발생하게 되었습니다.
  테스트를 할 때 apikey를 사용하는 부분을 mocking해서 할려고 했었고 고민을 해보았지만 쉽게 진행되지 않았습니다.

FIREBASE_API_KEY= "your api-key"
FIREBASE_AUTH_DOMAIN = "your auth-domain"
FIREBASE_DATA_BASEURL = "your data-baseurl"
FIREBASE_PROJECT_ID = "your project-id"
FIREBASE_STORAGE_BUCKET = "your storage-bucket"
FIREBASE_MESSAGING_SENDER_ID = "your messaging-sender-id"
FIREBASE_APP_ID = "your app-id"
FIREBASE_MEASUREMENT_ID = "your measurement-id"

• 그렇다가 우연치않게 Is it safe to expose Firebase apiKey to the public?라는 제목의 주제로 api 키를 공개하는 것이 안전한지에 대한 스택 오버플로우의 질문이 눈에 들어오게 되었습니다.
  그리고 이 부분에 대해서 계속 고민하게 되었고, 답은 저 글에 명확히 나와있지만 API Key라는 점이 걸려 제가 알게된 사실을 적어 공유해볼까 합니다.

💨 Is it safe to expose Firebase apiKey to the public?

• 고민의 발단이 된 스택오버플로우의 질문는 제목 그대로 firebase apikey를 공개를 하는 것이 안전한지에 대해서 물어본 것이였습니다.
  그 질문의 답변은 Google의 Firebase 엔지니어분이 달아주셨는데 그 답은 다음과 같았습니다.

• apiKey는 Google 서버에서 Firebase 프로젝트만 식별합니다. 누군가가 그것을 아는 것은 보안 위험이 아닙니다. 사실, 그들이 당신의 Firebase 프로젝트와 상호 작용하기 위해서는 그들이 그것을 알아야합니다. 이 동일한 구성 데이터는 Firebase를 백엔드로 사용하는 모든 iOS 및 Android 앱에도 포함됩니다.
• Firebase 백엔드 서비스에 대한 모든 데이터 액세스를 승인하는 방법을 알아 보려면 Firebase 보안 규칙에 대한 문서를 읽어 보세요. 이러한 규칙은 파일 저장소 및 데이터베이스 액세스에 대한 액세스를 제어하며 Firebase 서버에 적용됩니다.

• 이러한 답변으로 결론은 Firebase의 API-Key는 Google 서버에서 firebase 프로젝트만 식별하기 때문에 보안에 문제가 되지 않는다는 명확한 답변이였습니다. 하지만, 그 질문의 글은 무려 5년 전 질문이었고 API-key에 대한 의심은 있어서 더 찾아보게 되었습니다.

🐣 Firebase 공식 문서

• Firebase의 공식 문서에서 Firebase 용 API 키 사용 및 관리에 대해 알아보기라는 제목으로 Api key의 관리 방법이 자세히 설명되어있습니다.
• 여기서도 아래와 같이 Firebase용 API키는 일반적인 API키와 다르기 때문에 API키가 일반적으로 사용되는 방식과 달리 Firebase 서비스용 API키는 백엔드 리소스에 대한 액세스를 제어하는 데 사용 되지 않습니다. 라는 내용이 적혀있었습니다.

• 하지만 제가 진행하고 있던 개인 프로젝트는 이메일/비밀번호 로그인 방법으로 Firebase 인증을 사용하는 경우에 해당하였기 때문에 API키에 제한을 적용해야하는 구체적인 경우에 해당하게 되었습니다.
• 또한, 다른 구체적인 경우는 공식 문서 참고하시길 바랍니다.

📚 Firebase 보안 규칙

• 공식 문서의 내용에 따라 암호 기반 인증을 사용할 때 보호하는 방법인 firebase 보안 규칙을 사용할 수 있습니다.
  보안 규칙을 잘 적용하면 보안 규칙에 의해 보호되는 한 프로젝트의 데이터베이스 또는 저장소 데이터게 엑세스 할 수 없게 됩니다.
• 공식 문서의 보안 규칙에 굉장히 자세히 설명이 되어있으므로 참고하시기 바랍니다. 특히 안전하지 않은 규칙 차단을 참고하시면 좋을 거 같습니다.
• 만약 firestore 의 다음과 같은 규칙을 작성 후 적용합니다.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /groups/{group} {
      allow read: if true // 읽기 모두 허용
      // 쓰기: 콘텐츠 소유자 전용
      allow write: if request.auth != null && request.auth.uid == request.resource.data.author_uid 
    }
  }
}

본인이 작성한 것이 아닌 다른 사람이 작성한 것을 수정할려고 할 경우 다음과 같이 권한이 없어 거부되는 에러를 발생하게 됩니다.

• 다음은 인증된 사용자만 쓰기

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /groups/{group} {
      allow read: if true; // 읽기 모두 가능
      allow write: if request.auth.uid != null; // 쓰기 인증된 사용자만
    }
  }
}

• 추가적인 규칙은 공식 문서 참고 하시길 바랍니다.

🔥 다른 웹 사이트에서 Firebase 프로젝트에 생성, 수정 등을 못하게 하는 방법

• firebase를 사용하여 배포를 하게되고 내 프로젝트의 공개된 API-key를 사용해서 수정할 수 있는 여지가 생기게 됩니다.
• 예를 들어서 Github에 공개된 API-key를 사용해서 fork 후 로컬에서 프로젝트를 사용할 수 있게 됩니다. (localhost) 그렇게 되면 해당 구성 파일을 사용하여 새 사용자를 만들 수 있게 되고, 로컬에서 글을 작성, 수정 등을 할 수게 있게 됩니다.
• 이에 대한 해결 방법은 다음 블로그에 자세히 나와있고, 이 부분은 firebase 공식 문서의 출시 체크리스트 중 하나의 도메인 허용 목록을 추가하여 무단 사용을 방지합니다. 라고 소개되어있습니다. 또한, 구글의 firebase 엔지니어 Frank van Puffelen 께서 피싱 공격에 대해 이 방법을 언급하셨습니다.

1. Google Cloud Platform API 및 서비스에 접속하여 해당 프로젝트를 선택 후 사용자 인증 정보 탭으로 이동합니다.

2. 사용자 인증 정보 탭의 API 키 부분의 Browser Key (auto created by Firebase) 를 선택합니다.

3. 선택 후 API키 제한 및 이름 변경 페이지로 이동하게 되는데 그 부분에서 애플리케이션 제한 사항을 HTTP 리퍼러(웹사이트) 를 선택해줍니다.

4. 선택하면 아래에 웹사이트 제한사항 항목이 나타나게 되는데 그 항목에 배포되어 있는 해당 프로젝트 URL를 입력 후 저장을 합니다.

• 이렇게 모든 작업을 완료하면 다른 사이트에서 API를 사용할 수 없게 됩니다. 하지만 이렇게 하면 로컬에서 사용할 수 없게 됩니다.
  로컬에서 해당 API를 가지고 로그인을 시도해보았을 때 다음과 같이 403 에러가 나타나게 됩니다.

• 로컬에서 테스트 및 개발을 못하기 때문에 이를 해결하기 위해서는 새로운 firebase 프로젝트를 사용해야 합니다. 개발 및 테스트만을 위한 firebase 프로젝트를 생성하고 새롭게 만든 firebase 프로젝트의 환경 변수를 사용해서 테스트를 진행할 수 있습니다.
  아래와 같이 개발 환경에 따라 환경 변수를 설정해줄 수 있습니다.

import firebase from 'firebase/app';

import 'firebase/auth';
import 'firebase/firestore';

import devConfig from '../../config/dev'; // 개발 환경 설정
import prodConfig from '../../config/prod'; // 배포 환경 설정

const config = process.env.NODE_ENV === 'production'
  ? prodConfig
  : devConfig;

firebase.initializeApp(config);

const fireStore = firebase.firestore;

export default fireStore;

📌 하지만, 이렇게 설정하는거에 대해서 반박도 존재했습니다.

HTTP 리퍼러가 매우 쉽게 스푸핑 될 수 있다는 점으로 결국 이렇게 하는 건 소용이 없다는 점이였고, api key를 노출하거나 노출하지 않는 것은 중요하지 않고 이 방법은 실제로 이러한 구성 정보는 공개 된 것으로 간주된다는 말이였습니다.

🚀 결론

• 이런 저런 내용을 찾아보았지만 결국 결론은 firebase api키는 공개가 되도 상관이 없다는 점입니다. 하지만, 권한을 주어 더 안전하게 관리할 수 있다는 점입니다.
• .env로 api-key를 숨기더라도 위와 같이 권한이 거부될 때도 결국 api키의 정보가 노출됩니다.

• API는 Firebals/Google 서비스와 상호 작용할 때 Firebase 프로젝트를 식별하는 데 사용합니다. API 키 사용에 대한 공식 문서를 참고해주시면 됩니다.
• Google의 Firebase JS 모바일 개발자인 Jorge Vergara분도 메일로 FIrebase API 키를 숨겨야하느냐에 대한 메일이 한달에 3 ~ 4번이 온다고 합니다. 이 글에서 핵심은 결국 공개되도 문제가 되지 않는다는 점이였고, 아래와 같이 쓰신 글을 보고 확신을 가질 수 있게되었습니다.

apiKey를 안다는 것은 사람들이 당신의 모든 데이터를 즉시 해킹 할 수 있다는 것을 의미하는 것이 아니라 그들이 당신의 앱/프로젝트에 연결할 수 있다는 것을 의미합니다.

• 이 답변을 듣고 명확하게 이해할 수 있었습니다. 그렇기 때문에 연결에 대한 부분을 위와 같이 해결해주면 문제는 없다는 결론을 내렸습니다.

🙏 참고 링크

• 개인 프로젝트의 Firebase에 대한 참고 사항 이슈
• How to secure your Firebase project even when your API key is publicly available
• Do you need to hide your Firebase API keys for Ionic apps?
• Firebase Security & Rules
• Firebase 용 API 키 사용 및 관리에 대해 알아보기
• How to restrict Firebase data modification?
• Is it safe to expose Firebase apiKey to the public?
• Firebase 보안 규칙
• You do realize that HTTP referrers can be spoofed very easily right?