Controlli le sue regole di sicurezza Firebase su 26 errori comuni
Incolli le regole di Firestore, di Firebase Storage o di Realtime Database. Il controllo legge il testo e mostra quali percorsi permettono a chiunque di leggere o scrivere.
Risultato
Questa è un’analisi statica del testo incollato. Non vede custom claims, App Check, la forma dei dati né regole che non sono mai state pubblicate; il voto copre solo ciò che i 26 controlli riescono a leggere.
Cosa questo controllo non può vedere
Il controllo legge solo il testo incollato. Non vede custom claims, App Check, la forma dei suoi dati né regole che non sono mai state pubblicate, quindi un risultato pulito non significa che il progetto sia sicuro.
Tutti i 26 controlli
| Controllo | ID | Servizio | Gravità |
|---|---|---|---|
| Chiunque può scrivere su Firestore | fs-open-write | Firestore | Critica |
| Chiunque può leggere da Firestore | fs-open-read | Firestore | Media |
| Un match con wildcard ricorsivo è aperto | fs-recursive-wildcard-open | Firestore | Critica |
| Regole in modalità di test con scadenza | fs-test-mode-expiry | Firestore | Critica |
| Qualsiasi utente autenticato può scrivere | fs-auth-only-write | Firestore | Alta |
| Qualsiasi utente autenticato può leggere | fs-auth-only-read | Firestore | Media |
| Email considerata affidabile senza email_verified | fs-email-unverified | Firestore | Media |
| Ruolo letto dai dati della richiesta | fs-role-from-request | Firestore | Alta |
| Un wildcard ampio nasconde regole più severe | fs-wildcard-shadow | Firestore | Alta |
| Gli utenti possono scrivere il proprio ruolo (euristica) | fs-self-role-write | Firestore | Alta |
| La scrittura accetta qualsiasi campo (euristica) | fs-write-no-field-guard | Firestore | Media |
| read non è diviso in get e list | fs-read-not-split | Firestore | Info |
| Nessun rifiuto esplicito per impostazione predefinita | fs-no-default-deny | Firestore | Info |
| Le regole di Firestore non sono state lette | fs-parse-error | Firestore | Info |
| Chiunque può leggere i file di Storage | st-open-read | Storage | Media |
| Chiunque può scrivere su Storage | st-open-write | Storage | Critica |
| Il match {allPaths=**} è aperto | st-recursive-wildcard-open | Storage | Critica |
| Qualsiasi utente autenticato può scrivere su Storage | st-auth-only-write | Storage | Alta |
| Le regole di Storage non sono state lette | st-parse-error | Storage | Info |
| L’intero database è leggibile da chiunque | db-root-read-open | Realtime Database | Critica |
| L’intero database è scrivibile da chiunque | db-root-write-open | Realtime Database | Critica |
| Un nodo è leggibile da chiunque | db-open-read | Realtime Database | Media |
| Un nodo è scrivibile da chiunque | db-open-write | Realtime Database | Alta |
| Una regola del figlio è annullata dal padre | db-cascade-override | Realtime Database | Alta |
| Qualsiasi utente autenticato può leggere o scrivere l’intero database | db-auth-only-root | Realtime Database | Alta |
| Le regole di Realtime Database non sono state lette | db-parse-error | Realtime Database | Info |
Domande
Cosa guarda il controllo delle regole Firebase?
Legge le regole di sicurezza Firebase che incolla per Firestore, Cloud Storage e Realtime Database e cerca regole che permettono a chiunque di leggere o scrivere, regole che richiedono solo un utente autenticato, fiducia nei dati del client e schemi simili.
Il testo delle mie regole viene salvato?
No. Le regole vengono elaborate in memoria sulla rete di Cloudflare e scartate appena la risposta è stata inviata. Insieme al testo non viene salvato né registrato nulla.
Quanto posso incollare?
Fino a 48,000 caratteri in totale nei tre campi. Se le sue regole sono più lunghe, incolli la parte che vuole far controllare.
Perché una regola di lettura pubblica può andare bene?
Alcuni dati sono pubblici di proposito, come un catalogo prodotti o gli articoli di un blog. Per Firestore e Storage il controllo conta una lettura senza condizione come problema medio e toglie 10 punti, perché non può sapere se i dati sono privati. Se i dati sono pubblici di proposito, può accettare questo costo. Solo nella radice del Realtime Database giudica più grave una lettura aperta.
Cosa sono le regole in modalità di test?
Quando crea un database Firestore in modalità di test, la console scrive una regola che permette tutto fino a una certa scadenza, con request.time. Fino ad allora chiunque può leggere e scrivere; dopo, tutto viene negato e l’app smette di funzionare. La sostituisca con condizioni vere prima del lancio.
Come si propagano a cascata le regole di Realtime Database?
In Realtime Database una regola che concede l’accesso vale per tutto ciò che sta sotto, e un figlio non può ritirarla. Una regola più severa su un figlio sotto un padre permissivo non si applica mai, ed è per questo che il controllo la segnala.
Cosa significa il voto?
Riassume solo ciò che i controlli riescono a leggere nel testo incollato: un punteggio di 100 meno una penalità per ogni controllo fallito, stabilita dal problema più grave che quel controllo ha trovato, e qualsiasi problema critico dà F. Una voce media può anche essere un’euristica che chiede di verificare a mano, perché il solo testo non mostra se è un problema reale. Una A non dimostra che il progetto sia sicuro, perché custom claims, App Check e i dati stessi sono fuori portata.