[ Firebase ] 파이어베이스 API key를 .env에 넣어서 보호하고 싶었습니다만,

파이어베이스 API key가 노출되지 않도록 주의해야 한다고 하는데 ,  과연 API key가 노출되면 어떤 문제점이 있을까?

- API key를 통해 파이어베이스 데이터베이스나 저장소에 접근하고

  데이터를 읽거나 쓸 수 있어서 데이터가 유출되거나 손상될 수 있다.

- 악의적으로 API key를 남용하거나 과도한 요청을 보내서 불필요한 트래픽이 발생하면

  서비스 이용에 대한 비용이 증가할 수 있다.

-서비스를 부정 사용하는 경우가 발생할 할 수 있어

  해당 서비스를 제공하는 데 사용되는 서버나 자원에 대한 과도한 부하를 초래할 수 있다.

 

 

바닐라 자바스크립트 프로젝트에서 적용하고 싶었습니다만,

오브젝트 v1도 v2도, 아직은 자바스크립트의 기본기가 더 필요할 것 같다는 생각에

바닐라 자바스크립트로 만든 프로젝트다.

순수 자바스크립트만 사용하는 경우에는 .env 파일을 사용하는 기능은 내장되어 있지 않다.

파이어베이스 API key를 dotenv파일에 저장하고 사용하는 방식은

주로 프론트엔드 프레임워크(React,Vue,Angular 등)나 빌드 도구에서 지원하는 기능이다.

이는 주로 웹팩(Webpack), 바벨(Babel)등의 빌드 도구와 함께 사용되며,

환경 변수를 설정하여 클라이언트 측에서 .env파일의 내용을 접근할 수 있게 해준다.

 

그럼에도 바닐라 자바스크립트로 비슷하게 API키를 보관하고 사용하고 싶다면?

서버 측에서 API키를 받아오는 방식이나 서버에서 환경 변수를 설정하여 클라이언트에 전달하는 방식을 사용하거나 웹팩과 같은 빌드 도구로 번들링하여 환경 변수를 주입하는 방식을 적용할 수 있다고 한다.

이렇게 웹팩에 대한 공부의 필요성을 또 한번 느낀다.

 

 

 

구글링을 하다 보니 Firebase API key가 공개해도 괜찮은지에 대하여 꼼꼼하게 블로그에 정리한 글이 있길래 아래에 링크를 첨부해본다.

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

 

 

 

파이어베이스 서비스용  API 키는 코드에 포함해도 안전하지만 제한을 적용해야 하는 몇 가지 경우가 있는데

이메일/비밀번호 로그인 방법으로 Firebase 인증을 사용하는 경우도 들어간다.

즉, 내가 만든 오브젝트 프로젝트에는 API키에 제한을 적용해야 하는 구체적인 경우에 해당된다.

HTTP리퍼러라고 API키를 사용할 수 있는 웹사이트를 지정하는 방법이다.

 

***HTTP리퍼러 ( HTTP Referrer )란?

HTTP리퍼러란 웹 브라우저가 HTTP요청을 보낼 때, 해당 요청을 만들어내는 웹 페이지의 주소를 나타내는 HTTP헤더.

리퍼러는 서버에게 요청이 어디에서 시작되었는지에 대한 정보를 전달합니다.

(ex 현재 패이지를 요청한 이전 페이지가 어디인지, 이전 페이지의 URI).

일반적으로 사용자가 웹 브라우저 주소창에 URL을 입력하거나, 링크를 클릭하거나, 폼을 제출할 때

웹 페이지의 URL이 리퍼러로 사용됩니다. 사용자의 유입 경로를 파악하거나 분석할 수 있지만 보안이 필요한 페이지를

다른 웹 사이트로 접근할 때, 해당 페이지의 주소가 리퍼러에 노출될 수 있어 보안에 신경을 써야 합니다. 

 

 

 

API 키를 사용하여 인증  |  Google Cloud

 

그러나 저기 위의 블로그 쓰신 분께서도 찾아 보셨다시피

HTTP리퍼러는 매우 쉽게 스푸핑 될 수 있다는 단점이 있다고 한다.

 

 

***스푸핑 ( Spoofing )이란?

스푸핑은 눈속임(spoof)에서 파생된 용어로,  컴퓨터 네트워크에서 사용자의 신원을 위조하거나,

소스를 위조하여 다른 사용자, 시스템, 장치를 속이는 행위. 

스푸핑에는 IP 스푸핑, 이메일 스푸핑, 웺 사이트 스푸핑, DNS스푸핑, MAC주소 스푸핑 등이 있다.

 

 

 .env에 넣으면 API key는 과연 안전하게 관리가 되는 것일까?

개발자 도구 소스를 통해서나, 권한이 거부될 때에도 API key는 충분히 노출될 수 있다.

그렇지만 몇몇 글에서는 Firebase API키는 공개되어도 문제가 되지 않는다고 한다.

 

 

 

 

그러면 과도한 요청이나 데이터 손상을 방지할 수 있는 방법은 없을까?

파이어베이스 문서에서 추천하는 방식은 아래와 같다.

 

 

Firebase 로그인을 승인된 도메인에서만 허용하도록 하고

 

 

 

Cloud Firestore의 규칙으로 가서 아래와 같이 추가해준다.

service cloud.firestore {
	match /databases/{database}/documents {
    		match/users/{userID}{
            		allow create: if request.auth != null;
        		allow read, update,delete: if request.auth != null && request.auth.uid == userID;
		}
	}
}

로그인에 성공한 사용자라면 새로운 문서를 만들 수 있고,

로그인에 성공했고 문서명과 uid가 같으면 읽고, 수정하고, 삭제할 수 있게 했다.

참고로 파이어스토어에서 users라는 컬렉션에 존재하는 문서 이름은 uid로 들어오게 해두었다.

 

 

 

▼ 아래는 파이어스토어 보안 규칙에 대한 문서에서 가져온 내용과 링크

 

모든 match 문은 컬렉션이 아닌 문서를 가리켜야 합니다.

match 문은 match /cities/SF와 같이 특정 문서를 가리킬 수도 있고, 

match /cities/{city}와 같이 와일드 카드를 사용해 지정한 경로의 모든 문서를 가리킬 수도 있습니다.

(와일드 카드를 사용해 지정한 경로의 모든 문서를 가리킬 수 있다)

 

Cloud Firestore 보안 규칙 구성  |  Firebase

 

Cloud Firestore 보안 규칙 시작하기  |  Firebase