Mit Firebase Security Rules können Sie neue Daten basierend auf vorhandenen Daten in Ihrer Datenbank oder Ihrem Speicher-Bucket bedingt schreiben. Sie können auch Regeln schreiben, mit denen Datenvalidierungen erzwungen werden, indem Schreibvorgänge basierend auf den neuen Daten eingeschränkt werden. Im Folgenden finden Sie weitere Informationen zu Regeln, mit denen Sicherheitsbedingungen auf Grundlage vorhandener Daten erstellt werden.
Wählen Sie in jedem Abschnitt ein Produkt aus, um mehr über die Regeln zur Datenvalidierung zu erfahren.
Einschränkungen für neue Daten
Cloud Firestore
Wenn Sie sichergehen möchten, dass kein Dokument erstellt wird, das ein bestimmtes Feld enthält, können Sie das Feld in die allow
-Bedingung aufnehmen. Wenn Sie beispielsweise die Erstellung von Dokumenten mit dem Feld ranking
verhindern möchten, müssen Sie es in der Bedingung create
ausschließen.
service cloud.firestore {
match /databases/{database}/documents {
// Disallow
match /cities/{city} {
allow create: if !("ranking" in request.resource.data)
}
}
}
Realtime Database
Wenn Sie verhindern möchten, dass Daten mit bestimmten Werten in Ihre Datenbank aufgenommen werden, können Sie diese Werte in Ihre Regeln aufnehmen und Schreibvorgänge für sie verbieten. Wenn Sie beispielsweise alle Schreibvorgänge mit ranking
-Werten ablehnen möchten, müssen Sie Schreibvorgänge für alle Dokumente mit ranking
-Werten verbieten.
{
"rules": {
// Write is allowed for all paths
".write": true,
// Allows writes only if new data doesn't include a `ranking` child value
".validate": "!newData.hasChild('ranking')
}
}
Cloud Storage
Wenn Sie dafür sorgen möchten, dass eine Datei mit bestimmten Metadaten nicht erstellt wird, können Sie die Metadaten in die allow
-Bedingung aufnehmen. Wenn Sie beispielsweise die Erstellung von Dateien mit ranking
-Metadaten verhindern möchten, müssen Sie dies in der Bedingung create
untersagen.
service firebase.storage {
match /b/{bucket}/o {
match /files/{fileName} {
// Disallow
allow create: if !("ranking" in request.resource.metadata)
}
}
}
Vorhandene Daten in Firebase Security Rules verwenden
Cloud Firestore
Viele Anwendungen speichern Informationen zur Zugriffssteuerung als Felder in Dokumenten der Datenbank. Mit Cloud Firestore Security Rules kann anhand von Dokumentdaten dynamisch festgelegt werden, wann Zugriffe zugelassen und wann sie abgelehnt werden:
service cloud.firestore {
match /databases/{database}/documents {
// Allow the user to read data if the document has the 'visibility'
// field set to 'public'
match /cities/{city} {
allow read: if resource.data.visibility == 'public';
}
}
}
Die Variable resource
verweist auf das angeforderte Dokument und resource.data
ist eine Zuordnung aller Felder und Werte, die im Dokument gespeichert sind. Weitere Informationen zur Variable resource
finden Sie in der Referenzdokumentation.
Beim Schreiben von Daten möchten Sie möglicherweise eingehende Daten mit vorhandenen Daten vergleichen. So können Sie beispielsweise prüfen, ob sich ein Feld nicht geändert hat, ob ein Feld nur um eins erhöht wurde oder ob der neue Wert mindestens eine Woche in der Zukunft liegt.
In diesem Fall enthält die Variable request.resource
den zukünftigen Status des Dokuments, wenn Ihr Regelsatz den ausstehenden Schreibvorgang zulässt. Bei update
-Vorgängen, die nur einen Teil der Dokumentfelder ändern, enthält die Variable request.resource
den Status des ausstehenden Dokuments nach dem Vorgang. Sie können die Feldwerte in request.resource
prüfen, um unerwünschte oder inkonsistente Datenaktualisierungen zu vermeiden:
service cloud.firestore {
match /databases/{database}/documents {
// Make sure all cities have a positive population and
// the name is not changed
match /cities/{city} {
allow update: if request.resource.data.population > 0
&& request.resource.data.name == resource.data.name;
}
}
}
Realtime Database
In Realtime Database können Sie .validate
-Regeln verwenden, um Datenstrukturen zu erzwingen und Format und Inhalt von Daten zu validieren. Rules-Regeln werden nach der Überprüfung ausgeführt, ob eine .validate
-Regel Zugriff gewährt..write
Die .validate
-Regeln werden nicht kaskadiert. Wenn eine Validierungsregel für einen Pfad oder Unterpfad in der Regel fehlschlägt, wird der gesamte Schreibvorgang abgelehnt.
Außerdem wird bei der Validierung von Definitionen nur nach Werten gesucht, die nicht null sind. Anfragen zum Löschen von Daten werden ignoriert.
Beachten Sie die folgenden .validate
-Regeln:
{
"rules": {
// write is allowed for all paths
".write": true,
"widget": {
// a valid widget must have attributes "color" and "size"
// allows deleting widgets (since .validate is not applied to delete rules)
".validate": "newData.hasChildren(['color', 'size'])",
"size": {
// the value of "size" must be a number between 0 and 99
".validate": "newData.isNumber() &&
newData.val() >= 0 &&
newData.val() <= 99"
},
"color": {
// the value of "color" must exist as a key in our mythical
// /valid_colors/ index
".validate": "root.child('valid_colors/' + newData.val()).exists()"
}
}
}
}
Anfragen an eine Datenbank, die den obigen Regeln entsprechen, würden die folgenden Ergebnisse liefern:
JavaScript
var ref = db.ref("/widget"); // PERMISSION_DENIED: does not have children color and size ref.set('foo'); // PERMISSION DENIED: does not have child color ref.set({size: 22}); // PERMISSION_DENIED: size is not a number ref.set({ size: 'foo', color: 'red' }); // SUCCESS (assuming 'blue' appears in our colors list) ref.set({ size: 21, color: 'blue'}); // If the record already exists and has a color, this will // succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) // will fail to validate ref.child('size').set(99);
Objective-C
FIRDatabaseReference *ref = [[[FIRDatabase database] reference] child: @"widget"]; // PERMISSION_DENIED: does not have children color and size [ref setValue: @"foo"]; // PERMISSION DENIED: does not have child color [ref setValue: @{ @"size": @"foo" }]; // PERMISSION_DENIED: size is not a number [ref setValue: @{ @"size": @"foo", @"color": @"red" }]; // SUCCESS (assuming 'blue' appears in our colors list) [ref setValue: @{ @"size": @21, @"color": @"blue" }]; // If the record already exists and has a color, this will // succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) // will fail to validate [[ref child:@"size"] setValue: @99];
Swift
var ref = FIRDatabase.database().reference().child("widget") // PERMISSION_DENIED: does not have children color and size ref.setValue("foo") // PERMISSION DENIED: does not have child color ref.setValue(["size": "foo"]) // PERMISSION_DENIED: size is not a number ref.setValue(["size": "foo", "color": "red"]) // SUCCESS (assuming 'blue' appears in our colors list) ref.setValue(["size": 21, "color": "blue"]) // If the record already exists and has a color, this will // succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) // will fail to validate ref.child("size").setValue(99);
Java
FirebaseDatabase database = FirebaseDatabase.getInstance(); DatabaseReference ref = database.getReference("widget"); // PERMISSION_DENIED: does not have children color and size ref.setValue("foo"); // PERMISSION DENIED: does not have child color ref.child("size").setValue(22); // PERMISSION_DENIED: size is not a number Map<String,Object> map = new HashMap<String, Object>(); map.put("size","foo"); map.put("color","red"); ref.setValue(map); // SUCCESS (assuming 'blue' appears in our colors list) map = new HashMap<String, Object>(); map.put("size", 21); map.put("color","blue"); ref.setValue(map); // If the record already exists and has a color, this will // succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) // will fail to validate ref.child("size").setValue(99);
REST
# PERMISSION_DENIED: does not have children color and size curl -X PUT -d 'foo' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # PERMISSION DENIED: does not have child color curl -X PUT -d '{"size": 22}' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # PERMISSION_DENIED: size is not a number curl -X PUT -d '{"size": "foo", "color": "red"}' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # SUCCESS (assuming 'blue' appears in our colors list) curl -X PUT -d '{"size": 21, "color": "blue"}' \ https://docs-examples.firebaseio.com/rest/securing-data/example.json # If the record already exists and has a color, this will # succeed, otherwise it will fail since newData.hasChildren(['color', 'size']) # will fail to validate curl -X PUT -d '99' \ https://docs-examples.firebaseio.com/rest/securing-data/example/size.json
Cloud Storage
Bei der Auswertung von Regeln sollten Sie auch die Metadaten der Datei berücksichtigen, die hochgeladen, heruntergeladen, geändert oder gelöscht wird. So können Sie komplexe und leistungsstarke Regeln erstellen, mit denen Sie beispielsweise nur Dateien mit bestimmten Inhaltstypen hochladen oder nur Dateien löschen lassen, die eine bestimmte Größe überschreiten.
Das resource
-Objekt enthält Schlüssel/Wert-Paare mit Dateimetadaten, die in einem Cloud Storage-Objekt angezeigt werden. Diese Eigenschaften können in read
- oder write
-Anfragen geprüft werden, um die Datenintegrität zu gewährleisten. Das resource
-Objekt prüft Metadaten für vorhandene Dateien in Ihrem Cloud Storage-Bucket.
service firebase.storage {
match /b/{bucket}/o {
match /images {
match /{fileName} {
// Allow reads if a custom 'visibility' field is set to 'public'
allow read: if resource.metadata.visibility == 'public';
}
}
}
}
Sie können das request.resource
-Objekt auch für write
-Anfragen verwenden, z. B. für Uploads, Metadatenaktualisierungen und Löschungen. Das request.resource
-Objekt erhält Metadaten aus der Datei, die geschrieben wird, wenn write
zulässig ist.
Mit diesen beiden Werten können Sie unerwünschte oder inkonsistente Aktualisierungen verhindern oder Anwendungsbeschränkungen wie Dateityp oder ‑größe erzwingen.
service firebase.storage {
match /b/{bucket}/o {
match /images {
// Allow write files to the path "images/*", subject to the constraints:
// 1) File is less than 5MB
// 2) Content type is an image
// 3) Uploaded content type matches existing content type
// 4) Filename (stored in imageId wildcard variable) is less than 32 characters
match /{imageId} {
allow read;
allow write: if request.resource.size < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*')
&& request.resource.contentType == resource.contentType
&& imageId.size() < 32
}
}
}
}
Eine vollständige Liste der Attribute im Objekt resource
finden Sie in der Referenzdokumentation.