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

Firebase allow read, write: if true selitettynä: mitä se tekee ja kuinka se korjataan

Q: Mikä ero on if true :n ja if request.auth != null :n välillä?

if true sallii anonyymin pääsyn — kenelle tahansa internetissä. if request.auth != null vaatii minkä tahansa sisäänkirjautuneen käyttäjän, mikä on parempi mutta yhä väärin: kuka tahansa sovelluksesi käyttäjä voi lukea jokaisen muun käyttäjän datan. Tuotantosääntöjen täytyy rajata tiettyyn käyttäjään tai orgiin request.auth.uid == resource.data.owner_uid:lla tai vastaavalla.

Q: Entä jos sovellukseni on aidosti julkinen luettavaksi (blogi, tuotekatalogi)?

Sitten kirjoita eksplisiittisesti allow read: if true; allow write: if false; vain julkiseen collectioniin — älä jokaiseen collectioniin tietokannassasi. Käytä erillistä match-klausuulia collectionia kohti, äläkä koskaan käytä rekursiivista '{'document=**'}'-wildcardia kirjoitettavissa säännöissä.

<code>allow read, write: if true;</code> on yksittäin yleisin Firebase-virhekonfiguraatio tuotannossa. Se on test-mode-oletus, jota Firebase Console ehdottaa, kun luot uuden tietokannan, sääntö, jota AI-koodaustyökalut regeneroivat dokumentaatiosta, ja sääntö, joka avaa koko Firestore-tietokantasi kenelle tahansa internetissä. Tämä artikkeli selittää syntaksin tarkasti, näyttää, mitä hyökkääjä näkee säännön ollessa elossa, ja antaa neljä progressiivisesti tiukempaa korvaajaa, jotka sopivat eri käyttötapauksiin.

Syntaksi, rivi riviltä

Täydellinen Firestoren test-mode-sääntödokumentti on kuusi riviä:

firebase

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

Avattuna:

rules_version = '2'; valitsee v2-sääntömoottorin (nykyinen). Vanhemmat v1-säännöt ovat poistuvia.
service cloud.firestore rajaa lohkon Firestoreen. Realtime Database käyttää eri JSON-pohjaista syntaksia; Cloud Storage käyttää service firebase.storage:ia.
match /databases/{database}/documents sitoo erikoisen (default)-tietokannan (useimmilla projekteilla on vain yksi).
match /{document=**} on rekursiivinen wildcard. ** täsmää mitä tahansa polkua, millä tahansa syvyydellä. Yhdistettynä {document}:n kanssa tämä nappaa jokaisen dokumentin jokaisessa collectionissa — yksi match-klausuuli, joka hallitsee koko tietokantaa.
allow read, write: if true; on sääntörunko. Sekä read että write on sallittu; ehto if true on, no, aina tosi. read kattaa get- ja list-operaatiot; write kattaa create:n, update:n ja delete:n.

Nettovaikutus: kuka tahansa klientti Firebase-projektin ID:llä ja oikealla SDK:lla voi lukea tai kirjoittaa minkä tahansa dokumentin missä tahansa collectionissa. Autentikointia ei vaadita. Nopeusrajoituksia ei pakoteta.

Miksi Firebase toimittaa tämän oletuksena

Firebase haluaa, että koodaat ensimmäisten 30 sekunnin aikana projektin luomisen jälkeen. Vaihtoehto — pakottaa sinut kirjoittamaan oikea sääntö ennen kuin yksikään luku tai kirjoitus toimii — estäisi onboardingin. Joten Console tarjoaa kaksi vaihtoehtoa, kun luot tietokannan: Production mode (kiellä kaikki, sinä kirjoitat säännöt) tai Test mode (salli kaikki 30 päivän ajan). Useimmat kehittäjät klikkaavat test moden ja unohtavat sitten palata. Vanhemmissa projekteissa oli 30 päivän ajastin; nykyisissä projekteissa on rajaton if true-sääntö ilman automaattista vanhentumista.

Rakenteellinen ongelma: AI-koodaustyökalut kouluttautuvat dokumentaatiolla, opastusvideoilla ja Stack Overflow -vastauksilla, jotka näyttävät test-mode-säännöt. Kun pyydät Cursorilta tai Claude Codelta "miten asetan Firebasen", vastaus sisältää usein tarkalleen allow read, write: if true-lohkon, ikään kuin se olisi tuotantosääntö. AI ei tiedä — eikä sitä kehoteta tietämään — että sääntö ei ole tuotantoturvallinen.

Mitä hyökkääjä näkee

Konkreettisesti hyökkääjä, joka tietää Firebase-projektisi ID:n (poimittavissa minkä tahansa julkaistun sovelluksen paketista 30 sekunnissa) ja ajaa seuraavan, voi listata jokaisen dokumentin jokaisessa collectionissa:

Yksi autentikoimaton curl-pyyntö riittää enumeroimaan jokaisen collectionin. Katso korostettu lohko alla.

bash

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

Vastaus on täydellinen lista ylätason collectioneista. Jokaiselle collectionille toinen pyyntö palauttaa dokumentit. Tällä polulla ei ole nopeusrajoitusta, koska if true-säännöt hyväksyvät anonyymin liikenteen. Olemme nähneet Firebase-tietokantoja, joissa miljoonia dokumentteja on enumeroitu alle tunnissa.

Kirjoituspolulla: yksi POST {fields}:n kanssa luo uuden dokumentin. Hyökkääjät voivat saastuttaa collectionsi roskalla, sotkea käyttäjille näkyviä sivuja, jotka lukevat Firestoresta, tai käyttää tietokantaasi ilmaisena viestivälittäjänä — käyttölaskusi nousee jyrkästi, tutkit asiaa, lasku selittää ongelman.

Neljä tuotantoturvallista korvaajaa

Valitse korvaaja, joka sopii sovelluksesi datamalliin. Kaikki neljä olettavat, että sinulla on käyttäjäautentikointi (Firebase Auth tai mikä tahansa tarjoaja, joka myöntää Firebase ID -tokenin):

Vaihtoehto 1: Käyttäjäomisteiset dokumentit

Yleisin SaaS-kuvio. Dokumentit elävät polun /users/{userId}/... alla ja vain omistaja voi koskea niihin. 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;
}

Vaihtoehto 2: Omistajakenttä jokaisessa dokumentissa

Kun dokumentit elävät tasaisissa collectioneissa (eivät käyttäjä-ID:n alla), tallenna owner_uid-kenttä ja tarkista se. 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;
}

Vaihtoehto 3: Monitenantti-org-eristys

B2B-SaaSille, jossa data on org-rajattua. Tallenna org_id-kenttä jokaisessa dokumentissa ja tarkista se käyttäjän mukautettua claimia vastaan. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Vaatii mukautetun claimin asettamisen rekisteröitymisen yhteydessä Firebase Admin SDK:n kautta.

firebase

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

Vaihtoehto 4: Vain luku, julkinen sisältö

Markkinointisisällölle, julkisille profiileille, tuotekatalogeille — mille tahansa, mikä on aidosti julkista luettavaksi mutta vain hallinnollisesti kirjoitettavaksi. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. admin-mukautettu claim asetetaan vain hallintatileille.

firebase

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

Nopea tarkistuskysely

Ennen korjausta tarkista, onko if true todella elossa. Avaa Firebase Console → Firestore → Rules ja etsi if true:ta. Jos löydät sen mistä tahansa kommentin ulkopuolelta, sinulla on avoimen säännön löydös. Saman käyttöliittymän Rules-simulaattori antaa sinun toistaa hyökkääjän pyynnön paikallisesti — liitä anonyymi GET /users/somebody ja vahvista, että simulaattori palauttaa Allowed.

Ulkoinen vahvistus: aja FixVibe-skannaus tuotanto-URL:ääsi vastaan. baas.firebase-rules-tarkistus tutkii Firestore-, Realtime Database- ja Storage-sääntösi ja raportoi saman löydöksen, jonka hyökkääjä havaitsisi — riippumatta siitä, mitä Firebase Console näyttää.

Usein kysytyt kysymykset

Mikä ero on <code>if true</code>:n ja <code>if request.auth != null</code>:n välillä?

if true sallii anonyymin pääsyn — kenelle tahansa internetissä. if request.auth != null vaatii minkä tahansa sisäänkirjautuneen käyttäjän, mikä on parempi mutta yhä väärin: kuka tahansa sovelluksesi käyttäjä voi lukea jokaisen muun käyttäjän datan. Tuotantosääntöjen täytyy rajata tiettyyn käyttäjään tai orgiin request.auth.uid == resource.data.owner_uid:lla tai vastaavalla.

Vanhentaako Firebase <code>if true</code>-säännöt koskaan automaattisesti?

Vanhemmissa projekteissa (ennen 2023) oli 30 päivän ajastin, joka muunsi if true-säännöt if false:ksi. Nykyisissä projekteissa ei ole — sääntö säilyy rajattomasti, kunnes se korvataan manuaalisesti. Jos loit projektisi ennen vuotta 2023 ja sääntösi näyttävät hyviltä, tarkista kahdesti: ajastin saattoi jo kääntää ne if false:ksi, mikä blokkaa oman sovelluksesi.

Voinko käyttää tulevaisuuden päivämäärän aikaleimatarkistusta turvaverkkona?

Et — aikaleimaehto ei ole tietoturvakontrolli. Se vanhentaa avoimen säännön tulevana päivänä, mikä tarkoittaa, että hyökkääjillä on täysi pääsy siihen päivään asti. Ja unohdat päivän. Korvaa if true auth-rajatulla säännöllä, ei aikarajoitetulla.

Entä jos sovellukseni on aidosti julkinen luettavaksi (blogi, tuotekatalogi)?

Sitten kirjoita eksplisiittisesti allow read: if true; allow write: if false; vain julkiseen collectioniin — älä jokaiseen collectioniin tietokannassasi. Käytä erillistä match-klausuulia collectionia kohti, äläkä koskaan käytä rekursiivista {document=**}-wildcardia kirjoitettavissa säännöissä.

Seuraavat askeleet

Aja FixVibe-skannaus tuotanto-URL:ääsi vastaan — baas.firebase-rules-tarkistus vahvistaa, onko if true tällä hetkellä hyödynnettävissä julkisesta internetistä. Skannerin mekaniikkaa ja rinnakkaisia tunnistuksia Realtime Databaselle ja Storagelle varten katso Firebase-sääntöskanneri. Saman virhekonfiguraatioluokan osalta Supabasella, lue Supabase RLS -skanneri.