Corrige reglas inseguras

Usa esta guía para comprender las vulnerabilidades comunes en las reglas de seguridad de Firestore, revisar y proteger mejor tus propias reglas y probar los cambios antes de implementarlos.

Si recibes una alerta que indica que la base de datos de Firestore no está protegida de forma correcta, puedes modificar y pruebar las reglas de seguridad de Firestore para resolver las vulnerabilidades.

Ve a la pestaña Reglas de Firebase console para ver las reglas de seguridad existentes.

Comprende las reglas de seguridad de Firestore

Las reglas de seguridad de Firestore protegen los datos de usuarios maliciosos. Las reglas predeterminadas para cualquier instancia de Firestore creada en Firebase console impiden el acceso a todos los usuarios. Para desarrollar tu app y acceder a la base de datos, debes modificar esas reglas y, si es necesario, otorgarles acceso general a todos los usuarios del entorno de desarrollo. Sin embargo, antes de implementar la app en un entorno de producción, debes proteger los datos y configurar las reglas de manera adecuada.

Mientras desarrollas la app y pruebas diferentes opciones de configuración para las reglas, usa el emulador de Firestore a fin de ejecutar la app en un entorno de desarrollo local.

Situaciones comunes con reglas no seguras

Antes de implementar la app, debes revisar y actualizar las reglas de seguridad de Firestore que configuraste de forma predeterminada o mientras la desarrollabas con Firestone. Puedes asegurarte de proteger los datos de los usuarios si evitas los siguientes errores comunes.

Acceso abierto

Cuando configuraste Firestore, es posible que hayas establecido reglas para permitir el acceso abierto durante el desarrollo. Tal vez creas que eres el único usuario de la app, pero, si la implementaste, está disponible en Internet. Si no autenticas a los usuarios ni configuras reglas de seguridad, cualquier persona que adivine el ID del proyecto podrá robar, modificar o borrar los datos.

Qué debes evitar: Otorgar acceso de lectura y escritura a todos los usuarios. 
// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this rule set in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}
Solución: Configurar reglas que restrinjan el acceso de lectura y escritura.

Define reglas que tengan sentido en tu jerarquía de datos. Una de las soluciones comunes a este problema es la seguridad basada en los usuarios con Firebase Authentication. Obtén más información sobre cómo autenticar usuarios mediante reglas.

Solo para el propietario del contenido

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;

    }
  }
}

Acceso público y privado mixto

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

Acceso para cualquier usuario autenticado

A veces, las reglas de seguridad de Firestore verifican que un usuario haya accedido, pero no restringen el acceso según esa autenticación. Si una de las reglas incluye auth != null, confirma que quieres que cualquier usuario autenticado tenga acceso a los datos.

Qué debes evitar: Permitir que cualquier usuario autenticado tenga acceso de lectura y escritura a toda tu base de datos 
service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}
Solución: Limitar el acceso mediante condiciones de seguridad.

Cuando verifiques la autenticación, te recomendamos usar una de las propiedades de autenticación para restringir aún más el acceso de algunos usuarios a conjuntos de datos específicos. Obtén más información sobre cómo agregar condiciones de seguridad y el acceso según la función.

Acceso según la función

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    match /some_collection/{document} {
     allow read: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

Acceso según los atributos

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "admin" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}

Acceso público y privado mixto

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 write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}

Acceso cerrado

Otro enfoque común que puedes aplicar mientras desarrollas la app es mantener los datos bloqueados. Por lo general, esto significa que bloqueaste el acceso de lectura y escritura para todos los usuarios de la siguiente manera:

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Los SDK de Firebase Admin y Cloud Functions aún podrán acceder a la base de datos. Usa estas reglas cuando quieras usar Firestore como backend solo de servidor junto con el SDK de Firebase Admin. Aunque esta alternativa es segura, recomendamos que pruebes que los clientes de tu app puedan recuperar datos sin problemas.

Obtén más información sobre las reglas de seguridad de Firestore y cómo funcionan en Comienza a usar las reglas de seguridad de Firestore.

Revisa las reglas de seguridad de Firestore

Usa el emulador de Firestore para verificar el comportamiento de la app y las opciones de configuración de las reglas de seguridad de Firestore. Úsalo para ejecutar y automatizar las pruebas de unidades en un entorno local antes de implementar las modificaciones.

Para probar con rapidez la versión actualizada de las reglas de seguridad de Firestore en Firebase console, usa la herramienta de zona de prueba de reglas.

  1. Para abrir esta herramienta, haz clic en Zona de pruebas de reglas, en la pestaña Reglas.
  2. En la configuración de la Zona de pruebas de reglas, selecciona opciones para la prueba, como las siguientes:
    • Prueba de lectura o escritura
    • Una ubicación específica en la base de datos, como una ruta de acceso
    • Tipo de autenticación: ID de usuario específico, usuario anónimo autenticado o no autenticado
    • Datos del documento al que hacen referencia tus reglas de manera específica (por ejemplo, si las reglas requieren la presencia de un campo determinado antes de permitir una operación de escritura)
  3. Haz clic en Ejecutar y busca los resultados en el banner que está arriba de la ventana de reglas.