FixVibe

// docs / baas security / firebase if-true explainer

Firebase allow read, write: if true explicado: qué hace y cómo arreglarlo

<code>allow read, write: if true;</code> es la configuración errónea de Firebase más común en producción. Es el predeterminado del modo prueba que la consola de Firebase sugiere cuando creas una nueva base de datos, la regla que las herramientas de codificación con IA regeneran desde la documentación, y la regla que abre toda tu base de datos de Firestore a cualquiera en internet. Este artículo explica la sintaxis con precisión, muestra lo que ve un atacante cuando esta regla está activa, y te da cuatro reemplazos progresivamente más estrictos que encajan en distintos casos de uso.

La sintaxis, línea por línea

Un documento completo de reglas de modo prueba de Firestore son seis líneas:

firebase
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

Decodificado:

  • rules_version = '2'; selecciona el motor de reglas v2 (actual). Las reglas v1 más antiguas están en desuso.
  • service cloud.firestore acota el bloque a Firestore. Realtime Database usa una sintaxis basada en JSON diferente; Cloud Storage usa service firebase.storage.
  • match /databases/{database}/documents enlaza la base de datos especial (default) (la mayoría de proyectos solo tienen una).
  • match /{document=**} es un comodín recursivo. El ** coincide con cualquier ruta de cualquier profundidad. Combinado con {document}, captura cada documento de cada colección — una sola cláusula de match que gobierna toda la base de datos.
  • allow read, write: if true; es el cuerpo de la regla. Tanto read como write se permiten; la condición if true es, bueno, siempre verdadera. read cubre operaciones get y list; write cubre create, update y delete.

Efecto neto: cualquier cliente con el ID del proyecto Firebase y el SDK correcto puede leer o escribir cualquier documento de cualquier colección. No se requiere autenticación. No se aplican límites de tasa.

Por qué Firebase lo incluye como predeterminado

Firebase quiere que estés codificando en los primeros 30 segundos tras crear un proyecto. La alternativa — obligarte a escribir una regla correcta antes de que cualquier lectura o escritura funcione — bloquearía la incorporación. Así que la consola ofrece dos opciones cuando creas una base de datos: Modo producción (denegar todo, tú escribes las reglas) o Modo prueba (permitir todo durante 30 días). La mayoría de desarrolladores hace clic en modo prueba, y luego olvida volver a revisarlo. Los proyectos antiguos tenían el temporizador de 30 días; los proyectos actuales tienen una regla if true indefinida sin caducidad automática.

El problema estructural: las herramientas de codificación con IA entrenan con documentación, tutoriales y respuestas de Stack Overflow que muestran reglas de modo prueba. Cuando le preguntas a Cursor o Claude Code "cómo configuro Firebase", la respuesta a menudo incluye el bloque exacto allow read, write: if true como si fuera la regla de producción. La IA no sabe — y no se le induce a saber — que esta regla no es segura para producción.

Lo que ve un atacante

Concretamente, un atacante que conozca tu ID de proyecto Firebase (extraíble del bundle de cualquier aplicación desplegada en 30 segundos) y ejecute lo siguiente puede listar cada documento de cada colección:

Una sola solicitud curl no autenticada basta para enumerar cada colección. Consulta el bloque resaltado abajo.

bash
curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

La respuesta es la lista completa de colecciones de primer nivel. Para cada colección, una segunda solicitud devuelve documentos. No hay límite de tasa en esta ruta porque las reglas if true aceptan tráfico anónimo. Hemos visto bases de datos Firebase con millones de documentos enumeradas en menos de una hora.

En la ruta de escritura: un solo POST con {fields} crea un nuevo documento. Los atacantes pueden contaminar tus colecciones con basura, desfigurar páginas para usuarios que leen de Firestore o usar tu base de datos como un broker de mensajes gratis — tu factura de uso se dispara, investigas, la factura te explica el problema.

Cuatro reemplazos seguros para producción

Elige el reemplazo que encaje con el modelo de datos de tu aplicación. Los cuatro asumen que tienes autenticación de usuario (Firebase Auth o cualquier proveedor que emita un token de ID de Firebase):

Opción 1: Documentos propiedad del usuario

Patrón SaaS más común. Los documentos viven bajo /users/{userId}/... y solo el propietario puede tocarlos. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

firebase
match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

Opción 2: Campo de propietario en cada documento

Cuando los documentos viven en colecciones planas (no anidados bajo el ID de usuario), guarda un campo owner_uid y compruébalo. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

firebase
match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

Opción 3: Aislamiento multi-tenant por organización

Para SaaS B2B con datos acotados por organización. Guarda un campo org_id en cada documento y compruébalo contra el claim personalizado del usuario. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Requiere establecer el claim personalizado durante el registro vía el SDK Admin de Firebase.

firebase
allow read, write: if request.auth.token.org_id == resource.data.org_id;

Opción 4: Contenido público de solo lectura

Para contenido de marketing, perfiles públicos, catálogos de productos — cualquier cosa que sea genuinamente de lectura pública pero de escritura solo para administradores. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. El claim personalizado admin se establece solo en cuentas de administrador.

firebase
match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

Consulta de auditoría rápida

Antes de corregir, comprueba si if true está realmente activo. Abre Consola de Firebase → Firestore → Reglas y busca if true. Si lo encuentras en cualquier sitio fuera de un comentario, tienes un hallazgo de regla abierta. El simulador de reglas en la misma UI te permite replicar la solicitud del atacante localmente — pega un GET /users/somebody anónimo y confirma que el simulador devuelve Permitido.

Confirmación externa: ejecuta un escaneo de FixVibe contra tu URL de producción. La verificación baas.firebase-rules sondea tus reglas de Firestore, Realtime Database y Storage y reporta el mismo hallazgo que descubriría un atacante — independientemente de lo que muestre la consola de Firebase.

Preguntas frecuentes

¿Cuál es la diferencia entre <code>if true</code> y <code>if request.auth != null</code>?

if true permite acceso anónimo — cualquiera en internet. if request.auth != null requiere cualquier usuario autenticado, lo cual es mejor pero todavía está mal: cualquier usuario de tu aplicación puede leer los datos de cualquier otro usuario. Las reglas de producción deben acotarse al usuario u organización específicos vía request.auth.uid == resource.data.owner_uid o similar.

¿Firebase alguna vez expira automáticamente las reglas <code>if true</code>?

Los proyectos antiguos (pre-2023) tenían un temporizador de 30 días que convertía las reglas if true en if false. Los proyectos actuales no — la regla persiste indefinidamente hasta que se reemplaza manualmente. Si creaste tu proyecto antes de 2023 y tus reglas se ven bien, comprueba dos veces: el temporizador puede haberlas cambiado a if false, que bloquea tu propia aplicación.

¿Puedo usar una comprobación de marca de tiempo con fecha futura como red de seguridad?

No — una condición de marca de tiempo no es un control de seguridad. Expira la regla abierta en una fecha futura, lo que significa que hasta esa fecha los atacantes tienen acceso completo. Y olvidarás la fecha. Reemplaza if true por una regla acotada por autenticación, no por una limitada por tiempo.

¿Qué pasa si mi aplicación es genuinamente de lectura pública (blog, catálogo de productos)?

Entonces escribe explícitamente allow read: if true; allow write: if false; solo en la colección pública — no en todas las colecciones de tu base de datos. Usa una cláusula match separada por colección y nunca uses el comodín recursivo {document=**} en reglas escribibles.

Próximos pasos

Ejecuta un escaneo de FixVibe contra tu URL de producción — la verificación baas.firebase-rules confirma si if true es actualmente explotable desde el internet público. Para los detalles del escáner y las detecciones paralelas para Realtime Database y Storage, consulta Escáner de reglas de Firebase. Para la clase equivalente de configuración errónea en Supabase, lee Escáner de RLS de Supabase.

// escanea tu superficie de baas

Encuentra la tabla abierta antes que otra persona lo haga.

Introduce una URL de producción. FixVibe enumera los proveedores de BaaS con los que habla tu aplicación, identifica sus endpoints públicos y reporta lo que un cliente no autenticado puede leer o escribir. Gratis, sin instalación, sin tarjeta.

  • Plan gratuito — 3 escaneos al mes, sin tarjeta de registro.
  • Identificación pasiva de BaaS — no se requiere verificación de dominio.
  • Supabase, Firebase, Clerk, Auth0, Appwrite y más.
  • Prompts de corrección con IA en cada hallazgo — pégalos de vuelta en Cursor / Claude Code.
Ejecuta un escaneo gratis de BaaS →

no requiere registro

Firebase allow read, write: if true explicado: qué hace y cómo arreglarlo — Docs · FixVibe