Sjekk Firebase-reglene dine mot 26 vanlige feil
Lim inn sikkerhetsreglene for Firestore, Firebase Storage eller Realtime Database. Sjekken leser teksten og viser hvilke stier som lar hvem som helst lese eller skrive.
Resultat
Dette er statisk analyse av innlimt tekst. Den ser ikke custom claims, App Check, datastruktur eller regler som aldri ble publisert; karakteren dekker bare det de 26 sjekkene kan lese.
Hva denne sjekken ikke kan se
Sjekken leser bare teksten du limte inn. Den ser ikke custom claims, App Check, hvordan dataene dine er bygd opp eller regler som aldri ble publisert, så et rent resultat betyr ikke at prosjektet er trygt.
Alle 26 sjekker
| Sjekk | ID | Tjeneste | Alvorlighetsgrad |
|---|---|---|---|
| Hvem som helst kan skrive til Firestore | fs-open-write | Firestore | Kritisk |
| Hvem som helst kan lese fra Firestore | fs-open-read | Firestore | Middels |
| En rekursiv wildcard-match er åpen | fs-recursive-wildcard-open | Firestore | Kritisk |
| Testmodus-regler med utløpsdato | fs-test-mode-expiry | Firestore | Kritisk |
| Enhver innlogget bruker kan skrive | fs-auth-only-write | Firestore | Høy |
| Enhver innlogget bruker kan lese | fs-auth-only-read | Firestore | Middels |
| E-post stoles på uten email_verified | fs-email-unverified | Firestore | Middels |
| Rolle leses fra forespørselens data | fs-role-from-request | Firestore | Høy |
| En bred wildcard skjuler strengere regler | fs-wildcard-shadow | Firestore | Høy |
| Brukere kan skrive sin egen rolle (heuristikk) | fs-self-role-write | Firestore | Høy |
| Skrivinger godtar hvilke felt som helst (heuristikk) | fs-write-no-field-guard | Firestore | Middels |
| read er ikke delt i get og list | fs-read-not-split | Firestore | Info |
| Ingen eksplisitt standard nekt | fs-no-default-deny | Firestore | Info |
| Firestore-reglene kunne ikke tolkes | fs-parse-error | Firestore | Info |
| Hvem som helst kan lese Storage-filer | st-open-read | Storage | Middels |
| Hvem som helst kan skrive til Storage | st-open-write | Storage | Kritisk |
| Matchen {allPaths=**} er åpen | st-recursive-wildcard-open | Storage | Kritisk |
| Enhver innlogget bruker kan skrive til Storage | st-auth-only-write | Storage | Høy |
| Storage-reglene kunne ikke tolkes | st-parse-error | Storage | Info |
| Hele databasen kan leses av hvem som helst | db-root-read-open | Realtime Database | Kritisk |
| Hele databasen kan skrives av hvem som helst | db-root-write-open | Realtime Database | Kritisk |
| En node kan leses av hvem som helst | db-open-read | Realtime Database | Middels |
| En node kan skrives av hvem som helst | db-open-write | Realtime Database | Høy |
| En barneregel overstyres av forelderen | db-cascade-override | Realtime Database | Høy |
| Alle innloggede brukere kan lese eller skrive hele databasen | db-auth-only-root | Realtime Database | Høy |
| Realtime Database-reglene kunne ikke tolkes | db-parse-error | Realtime Database | Info |
Spørsmål
Hva ser Firebase-regelsjekken på?
Den leser Firebase-sikkerhetsreglene du limer inn for Firestore, Cloud Storage og Realtime Database, og leter etter regler som lar hvem som helst lese eller skrive, regler som bare krever en innlogget bruker, tillit til data fra klienten og lignende mønstre.
Lagres regelteksten min?
Nei. Reglene behandles i minnet i Cloudflares nettverk og forkastes når svaret er sendt. Ingenting lagres eller logges sammen med teksten.
Hvor mye kan jeg lime inn?
Opptil 48,000 tegn til sammen i de tre feltene. Hvis reglene dine er lengre, limer du inn den delen du vil ha sjekket.
Hvorfor kan en åpen leseregel være greit?
Noen data skal være offentlige, for eksempel en produktkatalog eller blogginnlegg. For Firestore og Storage teller sjekken en ubetinget lesing som et middels problem og trekker 10 poeng, fordi den ikke kan vite om dataene er private. Hvis dataene er offentlige med vilje, kan du godta den kostnaden. Bare i roten av Realtime Database vurderer den en åpen lesing som mer alvorlig.
Hva er testmodus-regler?
Når du oppretter en Firestore-database i testmodus, skriver konsollen en regel som tillater alt frem til en dato, med request.time. Frem til da kan hvem som helst lese og skrive; etterpå nektes alt og appen slutter å virke. Bytt den ut med ekte vilkår før lansering.
Hvordan kaskaderer reglene i Realtime Database?
I Realtime Database gjelder en regel som gir tilgang for alt under den, og et barn kan ikke ta den tilbake. En strengere regel på et barn under en tillatende forelder gjelder aldri, og derfor rapporterer sjekken den.
Hva betyr karakteren?
Den oppsummerer bare det sjekkene kan lese i den innlimte teksten: en poengsum fra 100 minus et fradrag for hver mislykkede sjekk, satt av det alvorligste problemet sjekken fant, og ethvert kritisk problem gir F. Et middels punkt kan også være en heuristikk som ber deg sjekke for hånd, fordi teksten alene ikke viser om det er et reelt problem. En A beviser ikke at prosjektet er sikkert, for custom claims, App Check og selve dataene er utenfor rekkevidde.