Reglas de Firebase en FlutterFlow: cómo configurarlas bien
Cómo funcionan las reglas de Firestore en FlutterFlow, qué valores cambiar antes de lanzar, cómo impedir que un usuario edite su rol y cómo probarlas.
Read in English →
En una app de FlutterFlow, las reglas de seguridad de Firestore son lo único que impide que un usuario lea o modifique los datos de otro, porque la app habla con la base de datos directamente desde el celular. FlutterFlow te deja definir, para cada colección, quién puede crear, leer, escribir y borrar documentos, y genera las reglas cuando haces clic en Deploy. Antes de lanzar, revisa cada colección: nada privado debería poder leerlo Everyone, los datos de cada usuario deben usar Tagged Users o Users Collection, la regla temporal del modo de prueba tiene que desaparecer y nadie debe poder editar campos como su propio rol.
En esta guía explicamos cada opción, los errores que aparecen con más frecuencia, cuándo escribir una regla personalizada y cómo probar y publicar sin dejarte afuera.
¿Por qué las reglas importan tanto en FlutterFlow?
Una app de FlutterFlow con Firebase no tiene un servidor propio entre el usuario y la base de datos. La app del celular consulta Firestore directamente, y cualquiera puede tomar la configuración de Firebase de tu app y mandar sus propias peticiones. Ocultar un botón o filtrar una lista en la interfaz no sirve contra eso. Firebase revisa las reglas en cada petición, y por eso son tu verdadero sistema de permisos.
¿Qué significa cada opción de reglas en FlutterFlow?
Las encuentras en los ajustes de Firestore de FlutterFlow, en la sección Firestore Rules. Cada colección tiene cuatro operaciones: Create, Read, Write (actualizar) y Delete. Para cada una eliges un nivel de acceso:
| Opción | A quién permite | Uso típico |
|---|---|---|
| Everyone | A cualquiera, con o sin sesión | Contenido de verdad público, como un catálogo |
| Authenticated Users | A cualquiera que haya iniciado sesión | Contenido que pueden ver todos los miembros |
| Tagged Users | A los usuarios referenciados en un campo del documento | Publicaciones, pedidos o notas de un usuario |
| Users Collection | Al usuario cuyo ID coincide con el ID del documento | Solo la colección users |
| No One | A nadie desde la app | Datos que solo debe tocar tu backend |
Tagged Users necesita un campo en el documento con una referencia al usuario o un texto con su ID, como created_by. Al elegirlo, FlutterFlow abre la ventana Tag Users, donde seleccionas ese campo. Asegúrate de que la app llene ese campo al crear el documento; si no, nadie va a coincidir.
¿Qué valores por defecto debo cambiar antes de lanzar?
Las colecciones nuevas pueden arrancar más abiertas de lo que crees
La documentación de FlutterFlow indica que una colección nueva arranca con Create y Read en Everyone. Sirve para una demo y está mal para casi cualquier dato real. Recorre cada colección y pregúntate: ¿alguien sin sesión debería poder leer esto? Para pedidos, mensajes, notas y perfiles, la respuesta es no.
FlutterFlow además marca como Has Private Data las colecciones que podrían tener información personal y te sugiere restringirlas. No ignores esa advertencia sin revisarla.
La regla del modo de prueba tiene que irse
Cuando una base de Firestore se crea en modo de prueba, arranca con una regla del estilo allow read, write: if request.time < ..., que permite a cualquiera hacer cualquier cosa hasta una fecha. La documentación de FlutterFlow dice que hay que quitarla y salir del modo de prueba antes de publicar. Abre la pestaña Rules de Firestore en la consola de Firebase y confirma que ya no está.
"Authenticated Users" no es "el dueño"
Poner Read o Write en Authenticated Users significa que cualquier usuario con sesión, incluido alguien que se registró hace cinco minutos, puede leer o cambiar todos los documentos de esa colección. Para lo que pertenece a una sola persona, usa Tagged Users en Read, Write y Delete.
¿Cómo evito que un usuario cambie su propio rol?
Es fácil pasarlo por alto. Si tu colección users tiene Write en Users Collection, cada usuario puede editar su propio documento, y eso incluye cualquier campo. Si ahí guardas algo como role, is_admin o plan, un usuario puede ponerle el valor que quiera con una sola petición.
Dos soluciones:
- Mueve los campos con privilegios a una colección que la app no pueda escribir (Write en No One) y cámbialos solo desde un backend, como una Cloud Function.
- O excluye la colección de las reglas que genera FlutterFlow y escribe una regla personalizada que bloquee los cambios en esos campos:
match /users/{userId} {
allow read: if request.auth != null && request.auth.uid == userId;
allow update: if request.auth != null && request.auth.uid == userId
&& !request.resource.data.diff(resource.data).affectedKeys()
.hasAny(['role', 'is_admin', 'plan']);
}¿Cuándo conviene escribir reglas personalizadas?
Las opciones de FlutterFlow resuelven bien la propiedad de los datos. No resuelven todo. Escribe reglas propias cuando necesites:
- Roles, por ejemplo administradores que pueden leer todos los pedidos:
allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin'; - Validar campos al crear, como comprobar que el
created_byde un pedido nuevo sea la persona que lo crea, para que nadie cree documentos a nombre de otro. - Acceso compartido, como miembros de un equipo que pueden leer el mismo proyecto.
Para hacerlo, marca Exclude en esa colección dentro de FlutterFlow, para que deje de generar su regla, y escribe la regla en la consola de Firebase, en Firestore Database, Rules. La documentación de reglas de seguridad de Firebase explica la sintaxis. Guarda una copia de tus reglas personalizadas en las notas del proyecto o en el repositorio.
¿Cómo publico y pruebo las reglas?
Las reglas solo se aplican cuando las despliegas. En FlutterFlow haz clic en Deploy; una ventana de revisión muestra las reglas antes y después del cambio, y Deploy Now las aplica. Lee esa comparación cada vez, sobre todo si también editas reglas en la consola, para que un despliegue no reemplace en silencio algo que escribiste a mano.
Después prueba como lo haría un atacante:
- Crea dos cuentas de prueba, A y B.
- Con A, crea un documento en cada colección privada.
- Entra como B e intenta abrir los documentos de A, por ejemplo desde una página que recibe el ID de un documento.
- Intenta lo mismo sin sesión.
- Usa el Rules Playground de la consola de Firebase para simular lecturas y escrituras como un usuario específico.
Si algo se rompe después de un despliegue, puedes volver atrás en la consola de Firebase: abre la pestaña Rules, toma el conjunto de reglas anterior del historial de la izquierda, pégalo y haz clic en Publish. Si un despliegue falla con "cloud resource location is not set", la documentación de FlutterFlow indica definir la Default GCP Resource Location en los ajustes del proyecto de Firebase, una vez configurado Firestore.
Recuerda que Firebase Storage tiene sus propias reglas para los archivos subidos, separadas de las de Firestore. Revísalas también.
Respuestas rápidas
¿Necesito reglas si mi app de FlutterFlow ya oculta los datos en la interfaz? Sí. La app lee Firestore directamente, así que cualquiera con tu configuración de Firebase puede saltarse la interfaz. Lo único que se hace cumplir son las reglas.
¿Qué significa Tagged Users en FlutterFlow? Que el acceso se limita al usuario referenciado en un campo elegido del documento, como created_by.
¿Por qué mis usuarios no ven sus datos después de cambiar las reglas? Lo más común es que el campo del dueño esté vacío o tenga un valor distinto al que espera la regla, o que las reglas nuevas no se hayan desplegado.
¿Puedo editar las reglas en la consola de Firebase en vez de FlutterFlow? Sí, para las colecciones marcadas como Exclude. Revisa la comparación de antes y después en cada despliegue desde FlutterFlow.
¿Quieres que revisemos tus reglas?
Las reglas son cortas, pero una opción equivocada puede dejar expuestos los datos de todos tus usuarios. Nuestro servicio para arreglar apps de FlutterFlow revisa reglas, estructura de datos y código personalizado, y el equipo de desarrollo de apps móviles puede encargarse de trabajos más grandes. Lee qué hacer cuando un usuario ve los datos de otro y nuestro checklist de seguridad para apps hechas con IA, o escríbenos.
