获取我们在 Firebase 峰会上发布的所有信息,了解 Firebase 可如何帮助您加快应用开发速度并满怀信心地运行应用。了解详情

Estructuración de las reglas de seguridad de Cloud Firestore

Las reglas de seguridad de Cloud Firestore le permiten controlar el acceso a documentos y colecciones en su base de datos. La sintaxis de reglas flexibles le permite crear reglas que coincidan con cualquier cosa, desde todas las escrituras en toda la base de datos hasta operaciones en un documento específico.

Esta guía describe la sintaxis básica y la estructura de las reglas de seguridad. Combine esta sintaxis con las condiciones de las reglas de seguridad para crear conjuntos de reglas completos.

Declaración de servicios y bases de datos

Las reglas de seguridad de Cloud Firestore siempre comienzan con la siguiente declaración:

service cloud.firestore {
  match /databases/{database}/documents {
    // ...
  }
}

La declaración del service cloud.firestore las reglas a Cloud Firestore, lo que evita conflictos entre las reglas de seguridad de Cloud Firestore y las reglas de otros productos, como Cloud Storage.

La declaración match /databases/{database}/documents especifica que las reglas deben coincidir con cualquier base de datos de Cloud Firestore en el proyecto. Actualmente, cada proyecto tiene solo una única base de datos denominada (default) .

Reglas básicas de lectura/escritura

Las reglas básicas consisten en una declaración de match que especifica una ruta de documento y una expresión de allow detalla cuándo se permite la lectura de los datos especificados:

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>;
    }
  }
}

Todas las declaraciones de coincidencia deben apuntar a documentos, no a colecciones. Una declaración de coincidencia puede apuntar a un documento específico, como en match /cities/SF o usar comodines para apuntar a cualquier documento en la ruta especificada, como en match /cities/{city} .

En el ejemplo anterior, la declaración de coincidencia utiliza la sintaxis de comodín {city} . Esto significa que la regla se aplica a cualquier documento de la colección de cities , como /cities/SF o /cities/NYC . Cuando se evalúan las expresiones de allow en la declaración de coincidencia, la variable de la city se resolverá en el nombre del documento de la ciudad, como SF o NYC .

Operaciones granulares

En algunas situaciones, es útil dividir la read y write en operaciones más granulares. Por ejemplo, es posible que su aplicación quiera aplicar condiciones diferentes en la creación de documentos que en la eliminación de documentos. O es posible que desee permitir lecturas de un solo documento pero denegar consultas grandes.

Una regla de read se puede dividir en get y list , mientras que una regla de write se puede dividir en create , update y 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>;
    }
  }
}

datos jerárquicos

Los datos en Cloud Firestore están organizados en colecciones de documentos, y cada documento puede extender la jerarquía a través de subcolecciones. Es importante comprender cómo interactúan las reglas de seguridad con los datos jerárquicos.

Considere la situación en la que cada documento de la colección de cities contiene una subcolección de landmarks de referencia. Las reglas de seguridad se aplican solo en la ruta coincidente, por lo que los controles de acceso definidos en la colección de cities no se aplican a la subcolección de landmarks de referencia. En su lugar, escribe reglas explícitas para controlar el acceso a las subcolecciones:

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>;
        }
    }
  }
}

Al anidar sentencias de match , la ruta de la sentencia de match interna siempre es relativa a la ruta de la sentencia de match externa. Por lo tanto, los siguientes conjuntos de reglas son equivalentes:

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>;
    }
  }
}

Comodines recursivos

Si desea que las reglas se apliquen a una jerarquía arbitrariamente profunda, use la sintaxis de comodín recursiva, {name=**} . Por ejemplo:

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>;
    }
  }
}

Cuando se usa la sintaxis de comodín recursivo, la variable comodín contendrá el segmento de ruta coincidente completo, incluso si el documento se encuentra en una subcolección profundamente anidada. Por ejemplo, las reglas enumeradas anteriormente coincidirían con un documento ubicado en /cities/SF/landmarks/coit_tower y el valor de la variable del document sería SF/landmarks/coit_tower .

Tenga en cuenta, sin embargo, que el comportamiento de los comodines recursivos depende de la versión de las reglas.

Versión 1

Las reglas de seguridad utilizan la versión 1 de forma predeterminada. En la versión 1, los comodines recursivos coinciden con uno o más elementos de ruta. No coinciden con una ruta vacía, por lo que match /cities/{city}/{document=**} coincide con documentos en subcolecciones pero no en la colección de cities , mientras que match /cities/{document=**} coincide con ambos documentos en el colección y subcolecciones de cities .

Los comodines recursivos deben aparecer al final de una declaración de coincidencia.

Versión 2

En la versión 2 de las reglas de seguridad, los comodines recursivos coinciden con cero o más elementos de ruta. match/cities/{city}/{document=**} coincide con los documentos de cualquier subcoleccion, así como con los documentos de la colección de cities .

Debe optar por la versión 2 agregando rules_version = '2'; en la parte superior de sus reglas de seguridad:

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>;
    }
  }
}

Puede tener como máximo un comodín recursivo por declaración de coincidencia, pero en la versión 2, puede colocar este comodín en cualquier parte de la declaración de coincidencia. Por ejemplo:

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>;
    }
  }
}

Si utiliza consultas de grupos de recopilación , debe utilizar la versión 2; consulte protección de consultas de grupos de recopilación .

Declaraciones de coincidencia superpuestas

Es posible que un documento coincida con más de una declaración de match . En el caso de que varias expresiones de allow coincidan con una solicitud, se permite el acceso si se true alguna de las condiciones:

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;
    }
  }
}

En el ejemplo anterior, se permitirán todas las lecturas y escrituras en la colección de cities porque la segunda regla siempre es true , aunque la primera regla siempre es false .

Límites de las reglas de seguridad

Cuando trabaje con reglas de seguridad, tenga en cuenta los siguientes límites:

Límite Detalles
Número máximo de llamadas a exist( exists() , get() y getAfter() por solicitud
  • 10 para solicitudes de un solo documento y solicitudes de consulta.
  • 20 para lecturas, transacciones y escrituras por lotes de varios documentos. El límite anterior de 10 también se aplica a cada operación.

    Por ejemplo, imagine que crea una solicitud de escritura por lotes con 3 operaciones de escritura y que sus reglas de seguridad usan 2 llamadas de acceso a documentos para validar cada escritura. En este caso, cada escritura usa 2 de sus 10 llamadas de acceso y la solicitud de escritura por lotes usa 6 de sus 20 llamadas de acceso.

Exceder cualquiera de los límites da como resultado un error de permiso denegado.

Algunas llamadas de acceso a documentos pueden almacenarse en caché y las llamadas almacenadas en caché no cuentan para los límites.

Profundidad máxima de declaración match anidada 10
Longitud máxima de ruta, en segmentos de ruta, permitida dentro de un conjunto de sentencias de match anidadas 100
Número máximo de variables de captura de ruta permitidas dentro de un conjunto de declaraciones de match anidadas 20
Profundidad máxima de llamada de función 20
Número máximo de argumentos de función 7
Número máximo de enlaces de variables let por función 10
Número máximo de llamadas a funciones recursivas o cíclicas 0 (no permitido)
Número máximo de expresiones evaluadas por solicitud 1,000
Tamaño máximo de un conjunto de reglas Los conjuntos de reglas deben obedecer dos límites de tamaño:
  • un límite de 256 KB en el tamaño de la fuente de texto del conjunto de reglas publicado desde Firebase console o desde la CLI mediante firebase deploy .
  • un límite de 250 KB en el tamaño del conjunto de reglas compilado que resulta cuando Firebase procesa la fuente y la activa en el back-end.

Próximos pasos