Las reglas de seguridad de Firebase le permiten controlar el acceso a sus datos almacenados. La sintaxis de reglas flexible significa que puede 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 algunos de los casos de uso más básicos que quizás desee implementar al configurar su aplicación y proteger sus datos. Sin embargo, antes de empezar a escribir reglas, es posible que desees aprender más sobre el idioma en el que están escritas y su comportamiento .
Para acceder y actualizar sus reglas, siga los pasos descritos en Administrar e implementar reglas de seguridad de Firebase .
Reglas predeterminadas: modo bloqueado
Cuando creas una base de datos o una instancia de almacenamiento en Firebase console, eliges si tus reglas de seguridad de Firebase restringen el acceso a tus datos ( modo bloqueado ) o permiten el acceso a cualquiera ( modo de prueba ). En Cloud Firestore y Realtime Database, las reglas predeterminadas para el modo bloqueado niegan el acceso a todos los usuarios. En Cloud Storage, solo los usuarios autenticados pueden acceder a los depósitos de almacenamiento.
Tienda de fuego en la nube
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
Base de datos en tiempo real
{
"rules": {
".read": false,
".write": false
}
}
Almacenamiento en la nube
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Reglas del entorno de desarrollo
Mientras trabaja en su aplicación, es posible que desee un acceso relativamente abierto o sin restricciones a sus datos. Solo asegúrese de actualizar sus Reglas antes de implementar su aplicación en producción. Recuerde también que si implementa su aplicación, será accesible públicamente, incluso si no la ha iniciado .
Recuerde que Firebase permite a los clientes acceder directamente a sus datos y las reglas de seguridad de Firebase son la única protección que bloquea el acceso de usuarios malintencionados. Definir reglas por separado de la lógica del producto tiene una serie de ventajas: los clientes no son responsables de hacer cumplir la seguridad, las implementaciones con errores no comprometerán sus datos y, lo más importante, no depende de un servidor intermediario para proteger los datos del mundo.
Todos los usuarios autenticados
Si bien no recomendamos dejar sus datos accesibles a ningún usuario que haya iniciado sesión, puede resultar útil configurar el acceso a cualquier usuario autenticado mientras desarrolla su aplicación.
Tienda de fuego en la nube
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}
Base de datos en tiempo real
{
"rules": {
".read": "auth.uid !== null",
".write": "auth.uid !== null"
}
}
Almacenamiento en la nube
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Reglas listas para producción
Mientras se prepara para implementar su aplicación, asegúrese de que sus datos estén protegidos y que el acceso se otorgue correctamente a sus usuarios. Aproveche la autenticación para configurar el acceso basado en usuarios y lea directamente desde su base de datos para configurar el acceso basado en datos.
Considere escribir reglas a medida que estructura sus datos, ya que la forma en que configura sus reglas afecta la forma en que restringe el acceso a los datos en diferentes rutas.
Acceso exclusivo para propietarios de contenido
Estas reglas restringen el acceso únicamente al propietario autenticado del contenido. Los datos solo los puede leer y escribir un usuario, y la ruta de datos contiene el ID del usuario.
Cuándo funciona esta regla: esta regla funciona bien si los datos están aislados por usuario, es decir, si el único usuario que necesita acceder a los datos es el mismo usuario que los creó.
Cuando esta regla no funciona: este conjunto de reglas no funciona cuando varios usuarios necesitan escribir o leer los mismos datos; los usuarios sobrescribirán los datos o no podrán acceder a los datos que han creado.
Para configurar esta regla: cree una regla que confirme que el usuario que solicita acceso para leer o escribir datos es el usuario propietario de esos datos.
Tienda de fuego en la nube
service cloud.firestore {
match /databases/{database}/documents {
// Allow only authenticated content owners access
match /some_collection/{userId}/{documents=**} {
allow read, write: if request.auth != null && request.auth.uid == userId
}
}
}
Base de datos en tiempo real
{
"rules": {
"some_path": {
"$uid": {
// Allow only authenticated content owners access to their data
".read": "auth !== null && auth.uid === $uid",
".write": "auth !== null && auth.uid === $uid"
}
}
}
}
Almacenamiento en la nube
// Grants a user access to a node matching their user ID
service firebase.storage {
match /b/{bucket}/o {
// Files look like: "user/<UID>/path/to/file.txt"
match /user/{userId}/{allPaths=**} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}
Acceso mixto público y privado
Esta regla permite que cualquiera pueda leer un conjunto de datos, pero restringe la capacidad de crear o modificar datos en una ruta determinada únicamente al propietario del contenido autenticado.
Cuándo funciona esta regla: esta regla funciona bien para aplicaciones que requieren elementos legibles públicamente, pero necesitan restringir el acceso de edición a los propietarios de esos elementos. Por ejemplo, una aplicación de chat o un blog.
Cuando esta regla no funciona: al igual que la regla de solo propietario de contenido, este conjunto de reglas no funciona cuando varios usuarios necesitan editar los mismos datos. En última instancia, los usuarios sobrescribirán los datos de los demás.
Para configurar esta regla: cree una regla que permita el acceso de lectura para todos los usuarios (o todos los usuarios autenticados) y confirme que el usuario que escribe los datos es el propietario.
Tienda de fuego en la nube
service cloud.firestore {
match /databases/{database}/documents {
// Allow public read access, but only content owners can write
match /some_collection/{document} {
allow read: if true
allow create: if request.auth.uid == request.resource.data.author_uid;
allow update, delete: if request.auth.uid == resource.data.author_uid;
}
}
}
Base de datos en tiempo real
{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data
"rules": {
"some_path": {
"$uid": {
".read": true,
// or ".read": "auth.uid !== null" for only authenticated users
".write": "auth.uid === $uid"
}
}
}
}
Almacenamiento en la nube
service firebase.storage {
match /b/{bucket}/o {
// Files look like: "user/<UID>/path/to/file.txt"
match /user/{userId}/{allPaths=**} {
allow read;
allow write: if request.auth.uid == userId;
}
}
}
Acceso basado en atributos y basado en roles
Para que estas reglas funcionen, debe definir y asignar atributos a los usuarios en sus datos. Las reglas de seguridad de Firebase verifican la solicitud con los datos de su base de datos o los metadatos del archivo para confirmar o denegar el acceso.
Cuándo funciona esta regla: si asigna una función a los usuarios, esta regla facilita la limitación del acceso según funciones o grupos específicos de usuarios. Por ejemplo, si estuviera almacenando calificaciones, podría asignar diferentes niveles de acceso al grupo "estudiantes" (leer solo su contenido), al grupo "maestros" (leer y escribir en su materia) y al grupo "directores" (leer todo el contenido).
Cuando esta regla no funciona: en Realtime Database y Cloud Storage, tus reglas no pueden aprovechar el método get() que las reglas de Cloud Firestore pueden incorporar. En consecuencia, debe estructurar su base de datos o metadatos de archivos para reflejar los atributos que está utilizando en sus reglas.
Para configurar esta regla: en Cloud Firestore, incluya un campo en los documentos de sus usuarios que pueda leer, luego estructure su regla para leer ese campo y otorgar acceso condicionalmente. En Realtime Database, cree una ruta de datos que defina los usuarios de su aplicación y les otorgue una función en un nodo secundario.
También puede configurar reclamos personalizados en Autenticación y luego recuperar esa información de la variable auth.token en cualquier regla de seguridad de Firebase.
Atributos y roles definidos por datos
Estas reglas solo funcionan en Cloud Firestore y Realtime Database.
Tienda de fuego en la nube
Recuerde que cada vez que sus reglas incluyan una lectura, como las reglas a continuación, se le facturará una operación de lectura en Cloud Firestore.
service cloud.firestore {
match /databases/{database}/documents {
// For attribute-based access control, Check a boolean `admin` attribute
allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
allow read: true;
// Alterntatively, for role-based access, assign specific roles to users
match /some_collection/{document} {
allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
}
}
}
Base de datos en tiempo real
{
"rules": {
"some_path": {
"${subpath}": {
//
".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
".read": true
}
}
}
}
Atributos y roles de reclamo personalizados
Para implementar estas reglas, configure reclamos personalizados en Firebase Authentication y luego aproveche los reclamos en sus reglas.
Tienda de fuego en la nube
service cloud.firestore {
match /databases/{database}/documents {
// For attribute-based access control, check for an admin claim
allow write: if request.auth.token.admin == true;
allow read: true;
// Alterntatively, for role-based access, assign specific roles to users
match /some_collection/{document} {
allow read: if request.auth.token.reader == "true";
allow write: if request.auth.token.writer == "true";
}
}
}
Base de datos en tiempo real
{
"rules": {
"some_path": {
"$uid": {
// Create a custom claim for each role or group
// you want to leverage
".write": "auth.uid !== null && auth.token.writer === true",
".read": "auth.uid !== null && auth.token.reader === true"
}
}
}
}
Almacenamiento en la nube
service firebase.storage {
// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
allow read: if resource.metadata.owner == request.auth.token.groupId;
allow write: if request.auth.token.groupId == groupId;
}
}
Atributos de arrendamiento
Para implementar estas reglas, configure la tenencia múltiple en Google Cloud Identity Platform (GCIP) y luego aproveche el inquilino en sus reglas. Los siguientes ejemplos permiten escrituras desde un usuario en un inquilino específico, por ejemplo tenant2-m6tyz
Tienda de fuego en la nube
service cloud.firestore {
match /databases/{database}/documents {
// For tenant-based access control, check for a tenantID
allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
allow read: true;
}
}
Base de datos en tiempo real
{
"rules": {
"some_path": {
"$uid": {
// Only allow reads and writes if user belongs to a specific tenant
".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
".read": "auth.uid !== null
}
}
}
}
Almacenamiento en la nube
service firebase.storage {
// Only allow reads and writes if user belongs to a specific tenant
match /files/{tenantId}/{fileName} {
allow read: if request.auth != null;
allow write: if request.auth.token.firebase.tenant == tenantId;
}
}