🔥 FIREBASE CLOUD FIRESTORE - Reglas de seguridad de la base de datos
En el post de hoy creamos una serie de reglas de seguridad de nuestra base de datos Cloud Firestore de Firebase. Es muy importante añadir reglas de seguridad que nos garanticen que nadie pueda acceder a todos los datos, o pueda hacer un borrado masivo. También aseguramos los datos de nuestros users.
Tabla de contenido
Hoy en SwiftBeta vamos a ver un tema muy importante y que suele pasar bastante desapercibido, y son las reglas de seguridad de nuestra base de datos. En nuestro caso aplicaremos varias reglas a la base de datos Cloud Firestore que hemos utilizado en los anteriores posts.
Al crear una base de datos podemos especificar una serie de reglas para que los users puedan leer, escribir y eliminar dentro de nuestra base de datos.
En la serie de videos anteriores dijimos que un requisito para poder usar nuestra base de datos y así guardar enlaces (links) es que los users deben estar préviamente autenticados, esto significa haber hecho un login con Email y Password o con Facebook/Meta.
Si no has visto los posts te los dejo por aquí, aquí tienes el video de autenticación con Email y Password:
SwiftBeta
Y aquí el video de autenticación con Facebook/Meta:
SwiftBeta
¿Cómo escribir reglas en tus bases de datos de Firebase?
Vamos a escribir una serie de normas muy sencillas, pero ¿dónde se escriben estás normas? Para ello nos vamos a nuestra consola de Firebase con la que ya estamos familiarizados.
Y una vez hemos entrado en nuestra base de datos, vamos a la sección de reglas. Aquí vemos las reglas por defecto que se crearon cuando nosotros creamos la base de datos hace unas semanas.
Vamos a entrar en detalle en qué hace cada línea, pero si te fijas, podemos leer y guardar información en nuestra base de datos ya que se cumple la única regla de nuestra base de datos basada en si la fecha es inferior al 9/1/2022.
request.time < timestamp.date(2022, 1, 9);Reglas de seguridad versión 2
La primera línea que vemos, al añadir rules_version especificamos qué versión de las reglas de seguridad queremos, en nuestro caso vamos a dejarlo como está y nos quedaremos con la versión 2.
Escribimos las reglas
Antes de leer, escribir o eliminar en nuestra base de datos Cloud Firestore se comprueban las reglas de seguridad. Si se cumplen, tenemos acceso a nuestra base de datos, y si estas no se cumplen no podemos acceder y por lo tanto tendríamos un error.
Si quisiéramos aceptar todas las peticiones a nuestra base de datos, podríamos hacer lo siguiente:
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if
allow read, write: if true;
}
}
}- rules_version, especifica la versión de las reglas de seguridad
- service, especifica el servicio que vamos a utilizar, en nuestro caso es la base de datos Cloud Firestore (solo se aplicarán estas reglas de seguridad aquí)
- match /databases/{database}/documents y match /{document=**}, aquí lo que hacemos es indicar que se apliquen las reglas en toda la jerarquía de nuestra base de datos. En cualquier documento de nuestra colección.
- allow, aquí indicamos que para lectura y escritura queremos retornar siempre true, indicando que cualquier user puede leer, escribir y eliminar en nuestra base de datos.
El problema de hacer esto es que le das permiso a cualquier user a alterar el contenido de tu base de datos, incluso de borrarla por completo.
Cómo probar las reglas de seguridad de nuestra base de datos Cloud Firestore
Si te fijas, en la misma vista en la que estamos trabajando, tenemos una Zona de prueba de reglas en esta sección podemos probar la regla que acabamos de añadir.
Para probar nuestra nueva regla de seguridad lo que vamos hacer es poner la colección links y a continuación pondremos un document ID que exista en nuestra base de datos. Y pulsamos en el Button Ejecutar. Si todo va bien debería aparecer lo mismo que vemos en la siguiente imagen:
Se autorizó la operación de lectura simulada
Esto lo hemos hecho como prueba, pero no nos interesa que todos los users tengan estos privilegios. Si queremos el caso opuesto, haríamos lo siguiente:
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}Aquí estamos bloqueando todas las solicitudes de nuestros users, y por lo tanto no permitimos realizar ninguna operación en nuestra base de datos.
Ahora vamos a añadir la única regla que queríamos en nuestra base de datos Cloud Firestore, y es la de solo permitir hacer consultas de lectura y escritura ha users que préviamente se hayan logueado.
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}Ahora vamos a probar esta opción en el simulador, aquí tenemos una opción que si la habilitamos podemos especificar el proveedor, en nuestro caso vamos a escoger password. No haría falta poner el correo electrónico.
Mejoramos nuestras reglas de seguridad
Ahora vamos hacer un pequeño cambio, y vamos a añadir que solo los users que se han autenticado con Email y Password o Facebook puedan realizar operaciones de lectura, escritura y eliminación de nuestra base de datos.
Para ello vamos a espeficicar en nuestra condición de la la regla de seguridad que el provider sea con password y facebook.com.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write:
if request.auth != null
&& (request.auth.token.firebase.sign_in_provider == "password"
|| request.auth.token.firebase.sign_in_provider == "facebook.com");
}
}
}Aquí podéis encontrar más información por si queréis añadir otros proveedores como Google, Github, Twitter, etc
Publicar reglas de seguirad nuevas
Una vez hemos modificado als reglas de seguridad que queremos, debemos publicarlas para que empiecen a funcionar. Para hacerlo le damos al Button de Publicar
Conclusión
Hoy hemos visto una leve pincelada de las reglas de Firebase. En realidad se pueden aplicar reglas mucho más complejas de colecciones dentro de colecciones. O añadir reglas de seguridad para que un user solo pueda modificar los documentos (en nuestro caso enlaces, links) que le pertenecen (los que ha creado).
