Tjek dine Firebase-regler mod 26 almindelige fejl
Indsæt sikkerhedsreglerne for Firestore, Firebase Storage eller Realtime Database. Tjekket læser teksten og viser, hvilke stier der lader hvem som helst læse eller skrive.
Resultat
Dette er statisk analyse af indsat tekst. Den kan ikke se custom claims, App Check, datastruktur eller regler, der aldrig blev udgivet; karakteren dækker kun det, som de 26 tjek kan læse.
Hvad dette tjek ikke kan se
Tjekket læser kun den indsatte tekst. Det kan ikke se custom claims, App Check, hvordan dine data er opbygget eller regler, der aldrig blev udgivet, så et rent resultat betyder ikke, at projektet er sikkert.
Alle 26 tjek
| Tjek | ID | Tjeneste | Alvorlighed |
|---|---|---|---|
| Hvem som helst kan skrive til Firestore | fs-open-write | Firestore | Kritisk |
| Hvem som helst kan læse fra Firestore | fs-open-read | Firestore | Mellem |
| Et rekursivt wildcard-match er åbent | fs-recursive-wildcard-open | Firestore | Kritisk |
| Testtilstand-regler med udløbsdato | fs-test-mode-expiry | Firestore | Kritisk |
| Enhver logget ind bruger kan skrive | fs-auth-only-write | Firestore | Høj |
| Enhver logget ind bruger kan læse | fs-auth-only-read | Firestore | Mellem |
| E-mail stoles på uden email_verified | fs-email-unverified | Firestore | Mellem |
| Rolle læses fra forespørgslens data | fs-role-from-request | Firestore | Høj |
| Et bredt wildcard skjuler strengere regler | fs-wildcard-shadow | Firestore | Høj |
| Brugere kan skrive deres egen rolle (heuristik) | fs-self-role-write | Firestore | Høj |
| Skrivninger accepterer alle felter (heuristik) | fs-write-no-field-guard | Firestore | Mellem |
| read er ikke delt i get og list | fs-read-not-split | Firestore | Info |
| Ingen eksplicit standardafvisning | fs-no-default-deny | Firestore | Info |
| Firestore-reglerne kunne ikke læses | fs-parse-error | Firestore | Info |
| Hvem som helst kan læse Storage-filer | st-open-read | Storage | Mellem |
| Hvem som helst kan skrive til Storage | st-open-write | Storage | Kritisk |
| Matchet {allPaths=**} er åbent | st-recursive-wildcard-open | Storage | Kritisk |
| Enhver logget ind bruger kan skrive til Storage | st-auth-only-write | Storage | Høj |
| Storage-reglerne kunne ikke læses | st-parse-error | Storage | Info |
| Hele databasen kan læses af hvem som helst | db-root-read-open | Realtime Database | Kritisk |
| Hele databasen kan skrives af hvem som helst | db-root-write-open | Realtime Database | Kritisk |
| En node kan læses af hvem som helst | db-open-read | Realtime Database | Mellem |
| En node kan skrives af hvem som helst | db-open-write | Realtime Database | Høj |
| En barneregel tilsidesættes af sin forælder | db-cascade-override | Realtime Database | Høj |
| Alle loggede ind brugere kan læse eller skrive hele databasen | db-auth-only-root | Realtime Database | Høj |
| Realtime Database-reglerne kunne ikke læses | db-parse-error | Realtime Database | Info |
Spørgsmål
Hvad kigger Firebase-regeltjekket på?
Det læser de Firebase-sikkerhedsregler, du indsætter for Firestore, Cloud Storage og Realtime Database, og leder efter regler, der lader hvem som helst læse eller skrive, regler der kun kræver en logget ind bruger, tillid til input fra klienten og lignende mønstre.
Gemmes min regeltekst?
Nej. Reglerne behandles i hukommelsen på Cloudflares netværk og kasseres, når svaret er sendt. Intet gemmes eller logges sammen med teksten.
Hvor meget kan jeg indsætte?
Op til 48,000 tegn i alt på tværs af de tre felter. Hvis dine regler er længere, så indsæt den del, du vil have tjekket.
Hvorfor kan en åben læseregel være i orden?
Nogle data skal være offentlige, som et produktkatalog eller blogindlæg. For Firestore og Storage tæller tjekket en ubetinget læsning som et mellemstort problem og trækker 10 point, fordi det ikke kan vide, om dataene er private. Hvis dataene er offentlige med vilje, kan du acceptere den pris. Kun i roden af Realtime Database vurderer det en åben læsning som mere alvorlig.
Hvad er testtilstand-regler?
Når du opretter en Firestore-database i testtilstand, skriver konsollen en regel, der tillader alt frem til en dato, med request.time. Indtil da kan hvem som helst læse og skrive; bagefter afvises alt, og appen holder op med at virke. Erstat den med rigtige betingelser før lancering.
Hvordan kaskaderer reglerne i Realtime Database?
I Realtime Database gælder en regel, der giver adgang, for alt under den, og et barn kan ikke tage den tilbage. En strengere regel på et barn under en tilladende forælder gælder aldrig, og derfor rapporterer tjekket den.
Hvad betyder karakteren?
Den opsummerer kun det, tjekkene kan læse i den indsatte tekst: en score fra 100 minus et fradrag for hvert mislykket tjek, fastsat af det alvorligste problem, tjekket fandt, og ethvert kritisk problem giver F. Et mellempunkt kan også være en heuristik, der beder dig tjekke i hånden, fordi teksten alene ikke viser, om det er et reelt problem. Et A beviser ikke, at projektet er sikkert, fordi custom claims, App Check og selve dataene er uden for rækkevidde.