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

Εξήγηση του Firebase allow read, write: if true: τι κάνει και πώς να το διορθώσεις

Q: Ποια είναι η διαφορά μεταξύ if true και if request.auth != null ;

Το if true επιτρέπει ανώνυμη πρόσβαση — οποιονδήποτε στο διαδίκτυο. Το if request.auth != null απαιτεί οποιονδήποτε συνδεδεμένο χρήστη, που είναι καλύτερο αλλά ακόμα λάθος: οποιοσδήποτε χρήστης της εφαρμογής σου μπορεί να διαβάσει τα δεδομένα κάθε άλλου χρήστη. Οι κανόνες παραγωγής πρέπει να εστιάζονται στον συγκεκριμένο χρήστη ή org μέσω request.auth.uid == resource.data.owner_uid ή παρόμοιο.

Q: Τι γίνεται εάν η εφαρμογή μου είναι γνήσια δημόσια για ανάγνωση (blog, κατάλογος προϊόντων);

Τότε γράψε ρητά allow read: if true; allow write: if false; μόνο στο δημόσιο collection — όχι σε κάθε collection στη βάση δεδομένων σου. Χρησιμοποίησε μια ξεχωριστή πρόταση match ανά collection και ποτέ μη χρησιμοποιείς το αναδρομικό wildcard '{'document=**'}' σε εγγράψιμους κανόνες.

Το <code>allow read, write: if true;</code> είναι η πιο συνηθισμένη εσφαλμένη ρύθμιση Firebase στην παραγωγή. Είναι η προεπιλογή test-mode που προτείνει η Firebase Console όταν δημιουργείς μια νέα βάση δεδομένων, ο κανόνας που τα εργαλεία κωδικοποίησης με ΤΝ αναδημιουργούν από την τεκμηρίωση και ο κανόνας που ανοίγει ολόκληρη τη βάση δεδομένων Firestore σου σε οποιονδήποτε στο διαδίκτυο. Αυτό το άρθρο εξηγεί τη σύνταξη με ακρίβεια, δείχνει τι βλέπει ένας επιτιθέμενος όταν αυτός ο κανόνας είναι ενεργός και σου δίνει τέσσερις προοδευτικά αυστηρότερες αντικαταστάσεις που ταιριάζουν σε διαφορετικές περιπτώσεις χρήσης.

Η σύνταξη, γραμμή προς γραμμή

Ένα πλήρες έγγραφο κανόνων test-mode του Firestore είναι έξι γραμμές:

firebase

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

Αποκωδικοποιημένο:

Το rules_version = '2'; επιλέγει τη μηχανή κανόνων v2 (τρέχουσα). Οι παλιότεροι κανόνες v1 είναι deprecated.
Το service cloud.firestore εστιάζει το μπλοκ στο Firestore. Το Realtime Database χρησιμοποιεί μια διαφορετική σύνταξη βασισμένη σε JSON· το Cloud Storage χρησιμοποιεί service firebase.storage.
Το match /databases/{database}/documents δεσμεύει την ειδική βάση δεδομένων (default) (τα περισσότερα project έχουν μόνο μία).
Το match /{document=**} είναι ένα αναδρομικό wildcard. Το ** ταιριάζει οποιαδήποτε διαδρομή οποιουδήποτε βάθους. Σε συνδυασμό με το {document}, αυτό αιχμαλωτίζει κάθε document σε κάθε collection — μια ενιαία πρόταση match που διέπει ολόκληρη τη βάση δεδομένων.
Το allow read, write: if true; είναι το σώμα του κανόνα. Τόσο το read όσο και το write επιτρέπονται· η συνθήκη if true είναι, λοιπόν, πάντα αληθής. Το read καλύπτει λειτουργίες get και list· το write καλύπτει create, update και delete.

Καθαρό αποτέλεσμα: οποιοσδήποτε client με το Firebase project ID και το σωστό SDK μπορεί να διαβάσει ή να γράψει οποιοδήποτε document σε οποιοδήποτε collection. Δεν απαιτείται authentication. Δεν επιβάλλονται rate limits.

Γιατί το Firebase το αποστέλλει ως προεπιλογή

Το Firebase θέλει να κωδικοποιείς στα πρώτα 30 δευτερόλεπτα μετά τη δημιουργία ενός project. Η εναλλακτική — να σε αναγκάζει να γράψεις έναν σωστό κανόνα πριν λειτουργήσει οποιαδήποτε ανάγνωση ή εγγραφή — θα μπλόκαρε το onboarding. Έτσι η Console προσφέρει δύο επιλογές όταν δημιουργείς μια βάση δεδομένων: Production mode (άρνηση όλων, γράφεις τους κανόνες) ή Test mode (να επιτρέπονται όλα για 30 ημέρες). Οι περισσότεροι προγραμματιστές κάνουν κλικ στο test mode και μετά ξεχνούν να επιστρέψουν. Παλαιότερα project είχαν τον χρονοδιακόπτη 30 ημερών· τρέχοντα project έχουν έναν αόριστο κανόνα if true χωρίς αυτόματη λήξη.

Το δομικό πρόβλημα: τα εργαλεία κωδικοποίησης με ΤΝ εκπαιδεύονται σε τεκμηρίωση, tutorials και απαντήσεις Stack Overflow που δείχνουν κανόνες test-mode. Όταν ζητάς από τα Cursor ή Claude Code «πώς ρυθμίζω το Firebase», η απάντηση συχνά περιλαμβάνει το ακριβές μπλοκ allow read, write: if true σαν να ήταν ο κανόνας παραγωγής. Η ΤΝ δεν ξέρει — και δεν ωθείται να ξέρει — ότι αυτός ο κανόνας δεν είναι ασφαλής για παραγωγή.

Τι βλέπει ένας επιτιθέμενος

Συγκεκριμένα, ένας επιτιθέμενος που γνωρίζει το Firebase project ID σου (εξάγεται σε 30 δευτερόλεπτα από το bundle οποιασδήποτε deployed εφαρμογής) και τρέχει τα ακόλουθα, μπορεί να απαριθμήσει κάθε document σε κάθε collection:

Ένα μοναδικό μη πιστοποιημένο αίτημα curl είναι αρκετό για την απαρίθμηση κάθε collection. Δες το επισημασμένο μπλοκ παρακάτω.

bash

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

Η απάντηση είναι η πλήρης λίστα των collections ανώτατου επιπέδου. Για κάθε collection, ένα δεύτερο αίτημα επιστρέφει documents. Δεν υπάρχει rate limit σε αυτή τη διαδρομή επειδή οι κανόνες if true δέχονται ανώνυμη κίνηση. Έχουμε δει βάσεις δεδομένων Firebase με εκατομμύρια documents να απαριθμούνται σε λιγότερο από μία ώρα.

Στη διαδρομή εγγραφής: ένα μοναδικό POST με {fields} δημιουργεί ένα νέο document. Οι επιτιθέμενοι μπορούν να μολύνουν τα collections σου με σκουπίδια, να παραμορφώσουν σελίδες προς τους χρήστες που διαβάζουν από το Firestore ή να χρησιμοποιήσουν τη βάση δεδομένων σου ως δωρεάν message broker — ο λογαριασμός χρήσης σου εκτοξεύεται, ερευνάς, ο λογαριασμός εξηγεί το πρόβλημα.

Τέσσερις αντικαταστάσεις ασφαλείς για παραγωγή

Επίλεξε την αντικατάσταση που ταιριάζει στο μοντέλο δεδομένων της εφαρμογής σου. Και οι τέσσερις υποθέτουν ότι έχεις authentication χρήστη (Firebase Auth ή οποιοσδήποτε πάροχος που εκδίδει token Firebase ID):

Επιλογή 1: Documents που ανήκουν σε χρήστες

Το πιο κοινό μοτίβο SaaS. Τα documents ζουν κάτω από /users/{userId}/... και μόνο ο ιδιοκτήτης μπορεί να τα αγγίξει. 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;
}

Επιλογή 2: Πεδίο ιδιοκτήτη σε κάθε document

Όταν τα documents ζουν σε επίπεδα collections (όχι nested κάτω από user ID), αποθήκευσε ένα πεδίο owner_uid και έλεγξέ το. 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;
}

Επιλογή 3: Πολυενοικιακή απομόνωση org

Για B2B SaaS με δεδομένα εστιασμένα σε org. Αποθήκευσε ένα πεδίο org_id σε κάθε document και έλεγξέ το εναντίον του custom claim του χρήστη. allow read, write: if request.auth.token.org_id == resource.data.org_id;. Απαιτεί ορισμό του custom claim κατά την εγγραφή μέσω του Firebase Admin SDK.

firebase

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

Επιλογή 4: Δημόσιο περιεχόμενο μόνο για ανάγνωση

Για περιεχόμενο marketing, δημόσια προφίλ, καταλόγους προϊόντων — οτιδήποτε είναι γνήσια δημόσιο για ανάγνωση αλλά μόνο από admin για εγγραφή. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. Το custom claim admin ορίζεται μόνο σε λογαριασμούς admin.

firebase

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

Γρήγορο query ελέγχου

Πριν διορθώσεις, έλεγξε εάν το if true είναι πραγματικά ενεργό. Άνοιξε Firebase Console → Firestore → Rules και ψάξε για if true. Εάν το βρεις οπουδήποτε εκτός σχολίου, έχεις εύρημα ανοιχτού κανόνα. Ο Rules simulator στο ίδιο UI σου επιτρέπει να αναπαράγεις τοπικά το αίτημα του επιτιθέμενου — επικόλλησε ένα ανώνυμο GET /users/somebody και επιβεβαίωσε ότι ο simulator επιστρέφει Allowed.

Εξωτερική επιβεβαίωση: τρέξε μια σάρωση FixVibe εναντίον του URL παραγωγής σου. Ο έλεγχος baas.firebase-rules διερευνά τους κανόνες Firestore, Realtime Database και Storage σου και αναφέρει το ίδιο εύρημα που θα ανακάλυπτε ένας επιτιθέμενος — ανεξάρτητα από αυτό που δείχνει η Firebase Console.

Συχνές ερωτήσεις

Ποια είναι η διαφορά μεταξύ <code>if true</code> και <code>if request.auth != null</code>;

Το if true επιτρέπει ανώνυμη πρόσβαση — οποιονδήποτε στο διαδίκτυο. Το if request.auth != null απαιτεί οποιονδήποτε συνδεδεμένο χρήστη, που είναι καλύτερο αλλά ακόμα λάθος: οποιοσδήποτε χρήστης της εφαρμογής σου μπορεί να διαβάσει τα δεδομένα κάθε άλλου χρήστη. Οι κανόνες παραγωγής πρέπει να εστιάζονται στον συγκεκριμένο χρήστη ή org μέσω request.auth.uid == resource.data.owner_uid ή παρόμοιο.

Λήγει το Firebase αυτόματα ποτέ τους κανόνες <code>if true</code>;

Παλιότερα project (πριν το 2023) είχαν χρονοδιακόπτη 30 ημερών που μετέτρεπε τους κανόνες if true σε if false. Τρέχοντα project δεν το έχουν — ο κανόνας παραμένει αόριστα μέχρι να αντικατασταθεί χειροκίνητα. Εάν δημιούργησες το project σου πριν το 2023 και οι κανόνες σου φαίνονται καλοί, δες προσεκτικά: ο χρονοδιακόπτης μπορεί να τους έχει ήδη γυρίσει σε if false, που μπλοκάρει τη δική σου εφαρμογή.

Μπορώ να χρησιμοποιήσω έναν έλεγχο μελλοντικού timestamp ως δίχτυ ασφαλείας;

Όχι — μια συνθήκη timestamp δεν είναι έλεγχος ασφαλείας. Λήγει τον ανοιχτό κανόνα σε μια μελλοντική ημερομηνία, που σημαίνει ότι μέχρι αυτή την ημερομηνία οι επιτιθέμενοι έχουν πλήρη πρόσβαση. Και θα ξεχάσεις την ημερομηνία. Αντικατάστησε το if true με έναν κανόνα εστιασμένο σε auth, όχι με έναν χρονικά οριοθετημένο.

Τι γίνεται εάν η εφαρμογή μου είναι γνήσια δημόσια για ανάγνωση (blog, κατάλογος προϊόντων);

Τότε γράψε ρητά allow read: if true; allow write: if false; μόνο στο δημόσιο collection — όχι σε κάθε collection στη βάση δεδομένων σου. Χρησιμοποίησε μια ξεχωριστή πρόταση match ανά collection και ποτέ μη χρησιμοποιείς το αναδρομικό wildcard {document=**} σε εγγράψιμους κανόνες.

Επόμενα βήματα

Τρέξε μια σάρωση FixVibe εναντίον του URL παραγωγής σου — ο έλεγχος baas.firebase-rules επιβεβαιώνει εάν το if true είναι αυτή τη στιγμή εκμεταλλεύσιμο από το δημόσιο διαδίκτυο. Για τους μηχανισμούς του scanner και τις παράλληλες ανιχνεύσεις για Realtime Database και Storage, δες Firebase rules scanner. Για την ισοδύναμη κατηγορία εσφαλμένης ρύθμισης στο Supabase, διάβασε Supabase RLS scanner.