Reglas de seguridad básicas en Firestore

Configurar reglas de seguridad en Firestore define quién puede leer, escribir, actualizar y borrar datos. Aquí se muestra cómo proteger una colección post con autenticación por UID, habilitar lectura pública tipo listado, y limitar actualización/borrado solo al autor validando UID y email. Además, se explica cómo usar la trazabilidad y el simulador para verificar cambios con confianza.

¿Cómo asegurar Firestore con reglas de autenticación?

Para evitar una base de datos “abierta” donde cualquiera con credenciales escriba, la primera medida es exigir autenticación. La regla base restringe todas las operaciones si no existe un usuario autenticado con UID.

• Problema inicial: la pestaña Reglas muestra advertencia porque está “totalmente abierto”.
• Objetivo: permitir leer, escribir, actualizar y borrar solo a usuarios autenticados.
• Clave: usar el campo de sesión autenticada con request.auth.uid distinto de null.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /post/{document} {
      // Solo usuarios autenticados pueden leer y escribir.
      allow read, write, update, delete: if request.auth.uid != null;
    }
  }
}

¿Qué implica aplicar y publicar reglas?

• Al “Publicar”, Firestore guarda la trazabilidad de las reglas para revertir o comparar cambios.
• Con el usuario autenticado: se pueden ver e insertar posts.
• Tras hacer sign out: las lecturas quedan bloqueadas al no cumplir la condición de autenticación.

¿Qué lecturas deben ser públicas en un blog con Firestore?

Un blog suele requerir que los visitantes puedan ver la lista de posts sin iniciar sesión. Para ello, se habilita el listado público y se mantiene el resto de operaciones bajo autenticación.

• Ajuste: quitar la restricción de lectura total y permitir “listar datos” de post.
• Regla práctica: habilitar list público con if true.
• Resultado: usuarios no autenticados pueden consultar los posts, mientras crear/actualizar/borrar sigue protegido.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /post/{document} {
      // Lista pública de posts.
      allow list: if true;
      // Resto de operaciones protegidas por autenticación.
      allow get, create, update, delete: if request.auth.uid != null;
    }
  }
}

¿Cómo se probó el flujo de acceso?

• Crear un post autenticado: funciona, se visualiza y se inserta sin problema.
• Hacer sign out y actualizar: ya no se ven los posts hasta ajustar reglas.
• Habilitar list público y recargar: los posts vuelven a ser visibles sin login.

¿Cómo limitar actualización y borrado por UID y email?

Para que solo el autor modifique o elimine su post, se comparan dos atributos: el UID del usuario autenticado y el email del token con los campos del documento existente.

• Condición 1: request.auth.uid == resource.data.uid.
• Condición 2: request.auth.token.email == resource.data.email.
• Beneficio: asegura que solo el creador, autenticado y con el mismo email, edite o borre.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /post/{uid} {
      // Solo el autor puede actualizar o borrar su propio post.
      allow update, delete: if request.auth.uid != null
                            && request.auth.uid == resource.data.uid
                            && request.auth.token.email == resource.data.email;
    }
  }
}

¿Qué herramientas ayudan a validar cambios?

• Trazabilidad: permite ver historial, comparar con la versión más reciente y restaurar reglas anteriores.
• Simulador: ejecuta pruebas de acceso sin necesidad de la aplicación, útil para validar escenarios de lectura y escritura.

¿Tienes dudas sobre estas reglas o quieres compartir variaciones para otros casos de uso? Deja tu comentario y conversemos.