FixVibe

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

Firebase allow read, write: if true explicado: o que fai e como corrixilo

<code>allow read, write: if true;</code> é a configuración incorrecta máis común de Firebase en produción. É o predeterminado en modo de proba que suxire a Consola de Firebase cando creas unha nova base de datos, a regra que as ferramentas de codificación con IA rexeneran a partir da documentación e a regra que abre toda a túa base de datos Firestore a calquera en internet. Este artigo explica a sintaxe con precisión, amosa o que ve un atacante cando esta regra está activa e dáche catro substitutos progresivamente máis estritos que se axustan a casos de uso diferentes.

A sintaxe, liña por liña

Un documento completo de regras de Firestore en modo de proba ten seis liñas:

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

Descodificado:

  • rules_version = '2'; selecciona o motor de regras v2 (actual). As regras v1 antigas están en desuso.
  • service cloud.firestore acoutado o bloque a Firestore. Realtime Database usa unha sintaxe diferente baseada en JSON; Cloud Storage usa service firebase.storage.
  • match /databases/{database}/documents liga a base de datos especial (default) (a maioría dos proxectos só teñen unha).
  • match /{document=**} é un comodín recursivo. O ** coincide con calquera camiño de calquera profundidade. Combinado con {document}, isto captura cada documento en cada colección — unha única cláusula match que goberna toda a base de datos.
  • allow read, write: if true; é o corpo da regra. Permítense ambos read e write; a condición if true é, ben, sempre verdadeira. read cubre as operacións get e list; write cubre create, update e delete.

Efecto neto: calquera cliente co ID do proxecto Firebase e o SDK correcto pode ler ou escribir calquera documento en calquera colección. Non se require autenticación. Non se impoñen límites de taxa.

Por que Firebase a envía como predeterminado

Firebase quere que estés codificando nos primeiros 30 segundos despois de crear un proxecto. A alternativa — facer que escribas unha regra correcta antes de que calquera lectura ou escritura funcione — bloquearía a incorporación. Así que a Consola ofrece dúas opcións cando creas unha base de datos: Modo produción (denegar todo, ti escribes as regras) ou Modo proba (permitir todo durante 30 días). A maioría dos desenvolvedores clican no modo proba e despois esquecen revisalo. Os proxectos antigos tiñan o temporizador de 30 días; os proxectos actuais teñen unha regra if true indefinida sen expiración automática.

O problema estrutural: as ferramentas de codificación con IA adéstranse en documentación, titoriais e respostas de Stack Overflow que amosan regras en modo de proba. Cando lle preguntas a Cursor ou a Claude Code "como configuro Firebase", a resposta inclúe a miúdo o bloque exacto allow read, write: if true coma se fose a regra de produción. A IA non sabe — e non se lle pide que saiba — que esta regra non é segura para produción.

Que ve un atacante

Concretamente, un atacante que coñece o ID do teu proxecto Firebase (extraíble de calquera bundle de aplicación despregada en 30 segundos) e executa o seguinte pode listar cada documento en cada colección:

Unha única solicitude curl non autenticada é suficiente para enumerar cada colección. Mira o bloque resaltado abaixo.

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

A resposta é a lista completa de coleccións de nivel superior. Para cada colección, unha segunda solicitude devolve documentos. Non hai límite de taxa neste camiño porque as regras if true aceptan tráfico anónimo. Vimos bases de datos Firebase con millóns de documentos enumeradas en menos dunha hora.

No camiño de escritura: un único POST con {fields} crea un novo documento. Os atacantes poden contaminar as túas coleccións con lixo, desfigurar páxinas orientadas a usuarios que len de Firestore, ou usar a túa base de datos como un broker de mensaxes gratuíto — a túa factura de uso dispárase, investigas, a factura explica o problema.

Catro substitutos seguros para produción

Escolle o substituto que coincide co modelo de datos da túa aplicación. Os catro asumen que tes autenticación de usuario (Firebase Auth ou calquera provedor que emita un ID token de Firebase):

Opción 1: Documentos propiedade do usuario

O patrón SaaS máis común. Os documentos viven baixo /users/{userId}/... e só o propietario pode tocalos. 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

Cando os documentos viven en coleccións planas (non anidadas baixo o ID de usuario), almacena un campo owner_uid e compróbao. 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: Illamento de organización multi-tenant

Para SaaS B2B con datos acoutados por organización. Almacena un campo org_id en cada documento e compróbao contra o claim personalizado do usuario. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Require establecer o claim personalizado durante o rexistro vía o SDK Admin de Firebase.

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

Opción 4: Contido público de só lectura

Para contido de marketing, perfís públicos, catálogos de produtos — calquera cousa que sexa xenuinamente pública para lectura pero só admin para escritura. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. O claim personalizado admin establécese só nas contas de administrador.

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

Consulta rápida de auditoría

Antes de arranxar, comproba se if true está realmente activo. Abre a Consola de Firebase → Firestore → Regras e busca if true. Se o atopas en calquera lugar fóra dun comentario, tes un achado de regra aberta. O simulador de regras na mesma IU permíteche reproducir a solicitude do atacante localmente — pega un GET /users/somebody anónimo e confirma que o simulador devolve Permitido.

Confirmación externa: executa un escaneo de FixVibe contra o teu URL de produción. A comprobación baas.firebase-rules sondea as túas regras de Firestore, Realtime Database e Storage e informa do mesmo achado que descubriría un atacante — independente do que amose a Consola de Firebase.

Preguntas frecuentes

Cal é a diferenza entre <code>if true</code> e <code>if request.auth != null</code>?

if true permite acceso anónimo — calquera en internet. if request.auth != null require calquera usuario rexistrado, o que é mellor pero aínda incorrecto: calquera usuario da túa aplicación pode ler os datos de calquera outro usuario. As regras de produción deben acoutarse ao usuario ou organización específicos vía request.auth.uid == resource.data.owner_uid ou similar.

Firebase fai expirar automaticamente as regras <code>if true</code> algunha vez?

Os proxectos antigos (anteriores a 2023) tiñan un temporizador de 30 días que convertía as regras if true en if false. Os proxectos actuais non — a regra persiste indefinidamente ata que sexa substituída manualmente. Se creaches o teu proxecto antes de 2023 e as túas regras parecen ben, comproba dúas veces: o temporizador puido xa convertilas en if false, o que bloquea a túa propia aplicación.

Podo usar unha comprobación de marca de tempo de data futura como rede de seguranza?

Non — unha condición de marca de tempo non é un control de seguranza. Expira a regra aberta nunha data futura, o que significa que ata esa data os atacantes teñen acceso completo. E esquecerás a data. Substitúe if true por unha regra con ámbito de autenticación, non por unha limitada no tempo.

Que pasa se a miña aplicación é xenuinamente de lectura pública (blog, catálogo de produtos)?

Entón escribe explicitamente allow read: if true; allow write: if false; só na colección pública — non en cada colección da túa base de datos. Usa unha cláusula match separada por colección e nunca uses o comodín recursivo {document=**} en regras escribibles.

Próximos pasos

Executa un escaneo de FixVibe contra o teu URL de produción — a comprobación baas.firebase-rules confirma se if true é actualmente explotable desde internet pública. Para a mecánica do escáner e as deteccións paralelas para Realtime Database e Storage, mira Escáner de regras de Firebase. Para a clase equivalente de configuración incorrecta en Supabase, le Escáner de RLS de Supabase.

// escanea a túa superficie baas

Atopa a táboa aberta antes de que outra persoa o faga.

Introduce un URL de produción. FixVibe enumera os provedores de BaaS cos que fala a túa aplicación, identifica os seus endpoints públicos e informa do que un cliente non autenticado pode ler ou escribir. Gratis, sen instalación, sen tarxeta.

  • Plan gratuíto — 3 escaneos ao mes, sen tarxeta de rexistro.
  • Identificación pasiva de BaaS — non se require verificación de dominio.
  • Supabase, Firebase, Clerk, Auth0, Appwrite e máis.
  • Prompts de corrección con IA en cada achado — pégaos de volta en Cursor / Claude Code.
Executa un escaneo BaaS gratuíto →

non require rexistro

Firebase allow read, write: if true explicado: o que fai e como corrixilo — Docs · FixVibe