Cloud Firestore 보안 규칙을 사용하면 데이터베이스의 문서 및 컬렉션에 대한 액세스를 제어할 수 있습니다. 유연한 규칙 구문을 사용하면 전체 데이터베이스에 대한 모든 쓰기에서 특정 문서에 대한 작업에 이르기까지 무엇이든 일치하는 규칙을 만들 수 있습니다.
이 가이드에서는 보안 규칙의 기본 구문 및 구조에 대해 설명합니다. 이 구문을 보안 규칙 조건 과 결합하여 완전한 규칙 집합을 만듭니다.
서비스 및 데이터베이스 선언
Cloud Firestore 보안 규칙은 항상 다음 선언으로 시작합니다.
service cloud.firestore {
match /databases/{database}/documents {
// ...
}
}
service cloud.firestore
선언은 규칙 범위를 Cloud Firestore로 지정하여 Cloud Firestore 보안 규칙과 Cloud Storage와 같은 다른 제품에 대한 규칙 간의 충돌을 방지합니다.
match /databases/{database}/documents
선언은 규칙이 프로젝트의 모든 Cloud Firestore 데이터베이스와 일치해야 함을 지정합니다. 현재 각 프로젝트에는 (default)
이라는 단일 데이터베이스만 있습니다.
기본 읽기/쓰기 규칙
기본 규칙은 문서 경로를 지정하는 match
문과 지정된 데이터를 읽을 때 자세히 설명하는 allow
표현식으로 구성됩니다.
service cloud.firestore {
match /databases/{database}/documents {
// Match any document in the 'cities' collection
match /cities/{city} {
allow read: if <condition>;
allow write: if <condition>;
}
}
}
모든 일치 문은 컬렉션이 아닌 문서를 가리켜야 합니다. match 문은 match /cities/SF
에서와 같이 특정 문서를 가리키거나 match /cities/{city}
에서와 같이 와일드카드를 사용하여 지정된 경로의 모든 문서를 가리킬 수 있습니다.
위의 예에서 일치 문은 {city}
와일드카드 구문을 사용합니다. 이는 규칙이 /cities/SF
또는 /cities/NYC
와 같은 cities
컬렉션의 모든 문서에 적용됨을 의미합니다. match 문의 allow
표현식이 평가되면 city
변수는 SF
또는 NYC
와 같은 도시 문서 이름으로 확인됩니다.
세분화된 운영
경우에 따라 read
및 write
를 보다 세분화된 작업으로 나누는 것이 유용합니다. 예를 들어 앱에서 문서 삭제와 문서 생성에 다른 조건을 적용할 수 있습니다. 또는 단일 문서 읽기는 허용하지만 대규모 쿼리는 거부할 수 있습니다.
read
규칙은 get
및 list
로 나눌 수 있고 write
규칙은 create
, update
및 delete
로 나눌 수 있습니다.
service cloud.firestore {
match /databases/{database}/documents {
// A read rule can be divided into get and list rules
match /cities/{city} {
// Applies to single document read requests
allow get: if <condition>;
// Applies to queries and collection read requests
allow list: if <condition>;
}
// A write rule can be divided into create, update, and delete rules
match /cities/{city} {
// Applies to writes to nonexistent documents
allow create: if <condition>;
// Applies to writes to existing documents
allow update: if <condition>;
// Applies to delete operations
allow delete: if <condition>;
}
}
}
계층적 데이터
Cloud Firestore의 데이터는 문서 컬렉션으로 구성되며 각 문서는 하위 컬렉션을 통해 계층 구조를 확장할 수 있습니다. 보안 규칙이 계층적 데이터와 상호 작용하는 방식을 이해하는 것이 중요합니다.
cities
컬렉션의 각 문서에 landmarks
하위 컬렉션이 포함되어 있는 상황을 고려하십시오. 보안 규칙은 일치하는 경로에만 적용되므로 cities
모음에 정의된 액세스 제어는 landmarks
하위 모음에 적용되지 않습니다. 대신 하위 컬렉션에 대한 액세스를 제어하는 명시적인 규칙을 작성하세요.
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
allow read, write: if <condition>;
// Explicitly define rules for the 'landmarks' subcollection
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
match
문을 중첩할 때 내부 match
문의 경로는 항상 외부 match
문의 경로에 상대적입니다. 따라서 다음 규칙 세트는 동일합니다.
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city} {
match /landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
}
service cloud.firestore {
match /databases/{database}/documents {
match /cities/{city}/landmarks/{landmark} {
allow read, write: if <condition>;
}
}
}
재귀 와일드카드
임의의 깊은 계층 구조에 규칙을 적용하려면 {name=**}
재귀 와일드카드 구문을 사용하세요. 예를 들어:
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{document=**} {
allow read, write: if <condition>;
}
}
}
재귀 와일드카드 구문을 사용할 때 와일드카드 변수는 문서가 깊게 중첩된 하위 컬렉션에 있는 경우에도 일치하는 전체 경로 세그먼트를 포함합니다. 예를 들어 위에 나열된 규칙은 /cities/SF/landmarks/coit_tower
에 있는 문서와 일치하며 document
변수의 값은 SF/landmarks/coit_tower
입니다.
그러나 재귀 와일드카드의 동작은 규칙 버전에 따라 다릅니다.
버전 1
보안 규칙은 기본적으로 버전 1을 사용합니다. 버전 1에서 재귀 와일드카드는 하나 이상의 경로 항목과 일치합니다. 빈 경로와 일치하지 않으므로 match /cities/{city}/{document=**}
는 하위 컬렉션에 있는 문서와 일치하지만 city 컬렉션에는 없습니다. 반면 match /cities/{document=**}
cities
하위 컬렉션의 문서와 일치합니다. cities
컬렉션 및 하위 컬렉션.
재귀 와일드카드는 일치 문의 끝에 와야 합니다.
버전 2
보안 규칙 버전 2에서 재귀 와일드카드는 0개 이상의 경로 항목과 일치합니다. match/cities/{city}/{document=**}
는 모든 하위 컬렉션의 문서와 cities
컬렉션의 문서를 일치시킵니다.
rules_version = '2';
보안 규칙 맨 위에:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the cities collection as well as any document
// in a subcollection.
match /cities/{city}/{document=**} {
allow read, write: if <condition>;
}
}
}
일치 문당 최대 하나의 재귀 와일드카드를 사용할 수 있지만 버전 2에서는 이 와일드카드를 일치 문 어디에나 배치할 수 있습니다. 예를 들어:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the songs collection group
match /{path=**}/songs/{song} {
allow read, write: if <condition>;
}
}
}
컬렉션 그룹 쿼리 를 사용하는 경우 버전 2를 사용해야 합니다. 컬렉션 그룹 쿼리 보안 을 참조하세요.
겹치는 일치 문
문서가 둘 이상의 match
문과 일치할 수 있습니다. 여러 allow
표현식이 요청과 일치하는 경우 조건 중 하나 라도 true
액세스가 허용됩니다.
service cloud.firestore {
match /databases/{database}/documents {
// Matches any document in the 'cities' collection.
match /cities/{city} {
allow read, write: if false;
}
// Matches any document in the 'cities' collection or subcollections.
match /cities/{document=**} {
allow read, write: if true;
}
}
}
위의 예에서 첫 번째 규칙이 항상 false
임에도 불구하고 두 번째 규칙이 항상 true
이므로 cities
컬렉션에 대한 모든 읽기 및 쓰기가 허용됩니다.
보안 규칙 제한
보안 규칙으로 작업할 때 다음 제한 사항에 유의하십시오.
한계 | 세부 |
---|---|
요청당 최대 exists() , get() 및 getAfter() 호출 수 |
한도를 초과하면 권한 거부 오류가 발생합니다. 일부 문서 액세스 호출은 캐시될 수 있으며 캐시된 호출은 제한에 포함되지 않습니다. |
최대 중첩 match 문 깊이 | 10 |
중첩된 match 문 세트 내에서 허용되는 경로 세그먼트의 최대 경로 길이 | 100 |
중첩된 match 문 집합 내에서 허용되는 최대 경로 캡처 변수 수 | 20 |
최대 함수 호출 깊이 | 20 |
최대 함수 인수 수 | 7 |
함수당 let 변수 바인딩의 최대 수 | 10 |
재귀 또는 순환 함수 호출의 최대 수 | 0(허용되지 않음) |
요청당 평가되는 최대 표현식 수 | 1,000 |
규칙 세트의 최대 크기 | 규칙 세트는 두 가지 크기 제한을 준수해야 합니다.
|
다음 단계
- 사용자 지정 보안 규칙 조건 을 작성합니다.
- 보안 규칙 참조 를 읽으십시오.