firebase security rules

프론트엔드 단에서 firebase function을 호출할 수 있는 위험이 남아있음

(백엔드가 없어서, 모든 것이 프론트엔드에서 실행되고 있기 때문)

때문에 누군가 코드를 보고 reverse engineering을 시도해서 프론트엔드를 해킹할 수 있음

→ firebase는 rules를 제공함

rule은 어떤 상태에 대해 작성하도록 되어있음

사람들이 내 database나 storage파일을 읽고 쓰는 것을 허용할지/차단할지 결정함

firestore에서 규칙을 누르면, 아래와 같이 뜨는데

이 테스트 규칙에서는 사용자의 읽기, 쓰기를 허용하는 역할을 하고 있음


match /{document=**} {
  allow read, write: if request.time < timestamp.date(2024, 5, 26);
}

만약 현재 시간이 적혀있는 시간 (24년 5월 26일)보다 이르면 true값을 가짐

사람들이 database에서 읽는 것을 허용하는 rule을 작성한다면

request.auth ≠ null이면 권한을 허용함

(누구든 권한이 있다면, 내 database로부터 read작업을 할 수 있다)

권한은 tweets collection에 대한 권한이고, 모든 document를 읽을 수 있음


rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /tweets/{doc} {
      allow read: if request.auth != null;
    }
  }
}

호스팅된 사이트로 돌아가서 보면,

로그인된 상태라면 정상적으로 tweet을 읽어오는 것을 볼 수 있음

하지만, 만약 아래의 규칙에서

read가 아닌, write로 바꾼다면, 정상작동 하지만

read에 대한 권한이 없기 때문에, 어떤 게시글도 뜨지 않는 것을 볼 수 있음

즉, 프로젝트가 빌드되면, 소스코드에서 사람들이 api키를 찾아서 쓸 수 있지만,

security rule을 사용하면, 구체적으로 허용된 작업만 할 수 있게 됨

api키를 알게 되더라도, 그들은 security rule을 바꿀 권한이 없음

이제 허가받지 않은 수정, 업데이트, 삭제에 대한 보호를 만들 것임

tweet을 게시한 본인만이 해당 tweet을 수정,삭제할 수 있게 하고 싶음


rules_version = '2';

service cloud.firestore {
  match /databases/{database}/documents {
    match /tweets/{doc} {
      allow read, write: if request.auth != null;
      allow delete, update: if request.auth.uid == resource.data.userId
    }
  }
}

만약 작업을 요청하는 사용자의 아이디가 resource 내부의 유저id와 같을 때만, 수정과 삭제를 허용

storage에서도 규칙을 설정할 수 있는데

이미지 크기나 확장자등도 지정할 수 있음


rules_version = '2';

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read: if request.auth != null
      allow write: if request.auth != null && resource.size < 2*1024*1024 && resource.contentType == "image/png"
  }
}