Firebase Security Rules: deja de dejar tu base de datos abierta
Las apps web de Firebase leen y escriben en Firestore, Realtime Database y Cloud Storage directamente desde el navegador, con un objeto de configuración que cualquiera puede ver. Las Security Rules son lo único que decide si una petición se permite. Las reglas que se quedan en modo de prueba, o que se aflojan hasta permitirlo todo, exponen tu base de datos entera a internet.
Qué es
Las Security Rules son un pequeño lenguaje de políticas que se evalúa en los servidores de Google en cada lectura y escritura. Cada bloque match apunta a una ruta — una colección, un documento, una carpeta de storage — y las sentencias allow indican qué operaciones se permiten y bajo qué condiciones, usando request.auth (quién hace la petición) y request.resource.data (lo que intenta escribir).
La configuración web de Firebase, incluida su apiKey, solo identifica tu proyecto: no es un secreto y no concede acceso por sí sola. Por eso las reglas importan tanto: cualquier visitante puede inicializar el SDK de Firebase con tu config y consultar tu base de datos directamente desde la consola de su propio navegador.
Por qué importa
El modo de prueba de Firestore permite todas las lecturas y escrituras hasta una fecha de caducidad. Cuando llega el plazo y la app deja de funcionar, un "arreglo" habitual es allow read, write: if true, que deja cada documento legible y modificable por todo el mundo. Las bases de datos de Firebase expuestas son una fuente recurrente de grandes filtraciones de datos, y encontrarlas y volcarlas es trivial.
Las reglas que solo comprueban request.auth != null no son mucho mejores: cualquiera puede crear una cuenta, a menudo de forma anónima, y luego leer los datos de todos los usuarios. Sin validar las escrituras, los usuarios también pueden editar campos que nunca deberían controlar, por ejemplo poner role: "admin" en su propio perfil.
Cómo solucionarlo
Deniega por defecto y concede acceso colección por colección. Aquí cada usuario solo puede leer y escribir su propio documento en users, y no se puede acceder a nada más.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /users/{userId} {
allow read, write: if request.auth != null
&& request.auth.uid == userId;
}
// Every other path is denied by default.
}
}Limita qué campos puede cambiar un usuario para que no pueda ascenderse a sí mismo ni manipular datos gestionados por el servidor. affectedKeys().hasOnly() rechaza cualquier actualización que toque otros campos.
match /users/{userId} {
allow update: if request.auth.uid == userId
&& request.resource.data.diff(resource.data)
.affectedKeys().hasOnly(["displayName", "photoURL"]);
}Busca en tus reglas match /{document=**} combinado con un allow amplio, if true y las marcas de tiempo de caducidad del modo de prueba. Recuerda que Cloud Storage y Realtime Database tienen archivos de reglas separados: protégelos también.
Usa el Rules Playground de la consola de Firebase o el Emulator Suite con @firebase/rules-unit-testing para ejecutar lecturas como usuario no autenticado y como otro usuario con sesión iniciada. Una comprobación externa rápida es una petición REST sin autenticar: si devuelve documentos, la colección es pública.
curl "https://firestore.googleapis.com/v1/projects/<project-id>/databases/(default)/documents/users"Preguntas frecuentes
¿La apiKey de Firebase es un secreto?
No. La apiKey de la configuración web de Firebase identifica tu proyecto y está pensada para enviarse al navegador. Protege tus datos con Security Rules y restringe la clave en Google Cloud a las APIs que tu app realmente usa, para que no pueda reutilizarse en otros servicios de pago de Google.
¿Basta con request.auth != null?
Casi nunca. Solo demuestra que quien hace la petición ha iniciado sesión, no que los datos le pertenezcan. Compara request.auth.uid con el propietario del documento, o comprueba un rol que los usuarios no puedan asignarse a sí mismos.
¿AppSafe revisa mis reglas de Firebase?
AppSafe no consulta tu proyecto de Firebase, así que no puede evaluar tus reglas: usa el Rules Playground o la comprobación con curl de arriba. Lo que sí hace es marcar las API keys de Google (el formato AIza…) que encuentra en tu JavaScript, porque ese mismo formato se usa para servicios de pago como Maps o Gemini. En una config web de Firebase es lo esperado; solo asegúrate de que la clave esté restringida.
¿Tu app está afectada?
AppSafe verifica este y docenas de problemas más en un solo escaneo gratis.
Escanear mi app gratisGuías relacionadas
Row Level Security (RLS) en Supabase: protege tus tablas
Tu anon key es pública. RLS es lo único que la separa de tus datos.
API keys expuestas en el JavaScript del cliente
Todo lo que va en tu bundle es público. Trátalo como tal.
Backups de base de datos expuestos: qué pasa cuando /backup.sql es accesible
Un volcado .sql accesible es la entrega completa de toda tu base de datos.