Kontrollera dina Firebase-regler mot 26 vanliga misstag
Klistra in dina säkerhetsregler för Firestore, Firebase Storage eller Realtime Database. Kontrollen läser texten och visar vilka sökvägar som låter vem som helst läsa eller skriva.
Resultat
Det här är statisk analys av inklistrad text. Den ser inte custom claims, App Check, datans uppbyggnad eller regler som aldrig har publicerats; betyget gäller bara det som de 26 kontrollerna kan läsa.
Vad den här kontrollen inte kan se
Kontrollen läser bara den inklistrade texten. Den ser inte custom claims, App Check, hur din data är uppbyggd eller regler som aldrig har publicerats, så ett rent resultat betyder inte att projektet är säkert.
Alla 26 kontroller
| Kontroll | ID | Tjänst | Allvarlighetsgrad |
|---|---|---|---|
| Vem som helst kan skriva till Firestore | fs-open-write | Firestore | Kritisk |
| Vem som helst kan läsa från Firestore | fs-open-read | Firestore | Medel |
| En rekursiv wildcard-match är öppen | fs-recursive-wildcard-open | Firestore | Kritisk |
| Testläge-regler med utgångsdatum | fs-test-mode-expiry | Firestore | Kritisk |
| Vilken inloggad användare som helst kan skriva | fs-auth-only-write | Firestore | Hög |
| Vilken inloggad användare som helst kan läsa | fs-auth-only-read | Firestore | Medel |
| E-post betros utan email_verified | fs-email-unverified | Firestore | Medel |
| Roll läses från begärans data | fs-role-from-request | Firestore | Hög |
| En bred wildcard döljer striktare regler | fs-wildcard-shadow | Firestore | Hög |
| Användare kan skriva sin egen roll (heuristik) | fs-self-role-write | Firestore | Hög |
| Skrivningar accepterar vilka fält som helst (heuristik) | fs-write-no-field-guard | Firestore | Medel |
| read är inte delad i get och list | fs-read-not-split | Firestore | Info |
| Ingen uttrycklig standardnekan | fs-no-default-deny | Firestore | Info |
| Firestore-reglerna kunde inte tolkas | fs-parse-error | Firestore | Info |
| Vem som helst kan läsa Storage-filer | st-open-read | Storage | Medel |
| Vem som helst kan skriva till Storage | st-open-write | Storage | Kritisk |
| Matchen {allPaths=**} är öppen | st-recursive-wildcard-open | Storage | Kritisk |
| Vilken inloggad användare som helst kan skriva till Storage | st-auth-only-write | Storage | Hög |
| Storage-reglerna kunde inte tolkas | st-parse-error | Storage | Info |
| Hela databasen kan läsas av vem som helst | db-root-read-open | Realtime Database | Kritisk |
| Hela databasen kan skrivas av vem som helst | db-root-write-open | Realtime Database | Kritisk |
| En nod kan läsas av vem som helst | db-open-read | Realtime Database | Medel |
| En nod kan skrivas av vem som helst | db-open-write | Realtime Database | Hög |
| En barnregel överstyrs av sin förälder | db-cascade-override | Realtime Database | Hög |
| Alla inloggade användare kan läsa eller skriva hela databasen | db-auth-only-root | Realtime Database | Hög |
| Realtime Database-reglerna kunde inte tolkas | db-parse-error | Realtime Database | Info |
Frågor
Vad tittar Firebase-regelkontrollen på?
Den läser de Firebase-säkerhetsregler du klistrar in för Firestore, Cloud Storage och Realtime Database och letar efter regler som låter vem som helst läsa eller skriva, regler som bara kräver en inloggad användare, förtroende för indata från klienten och liknande mönster.
Sparas min regeltext?
Nej. Reglerna bearbetas i minnet i Cloudflares nätverk och raderas när svaret har skickats. Ingenting sparas eller loggas tillsammans med texten.
Hur mycket kan jag klistra in?
Upp till 48,000 tecken sammanlagt i de tre fälten. Om dina regler är längre, klistra in den del du vill ha kontrollerad.
Varför kan en öppen läsregel vara okej?
Vissa data ska vara publika, som en produktkatalog eller blogginlägg. För Firestore och Storage räknar kontrollen en villkorslös läsregel som ett medelproblem och drar 10 poäng, eftersom den inte kan veta om datan är privat. Om datan är publik med flit kan du acceptera den kostnaden. Bara i roten av Realtime Database bedömer den en öppen läsning som allvarligare.
Vad är testläge-regler?
När du skapar en Firestore-databas i testläge skriver konsolen en regel som tillåter allt fram till ett datum, med request.time. Fram till då kan vem som helst läsa och skriva; efteråt nekas allt och appen slutar fungera. Byt ut den mot riktiga villkor före lansering.
Hur kaskaderar reglerna i Realtime Database?
I Realtime Database gäller en regel som ger åtkomst för allt under den, och ett barn kan inte ta tillbaka den. En striktare regel på ett barn under en tillåtande förälder gäller aldrig, och därför rapporterar kontrollen den.
Vad betyder betyget?
Det sammanfattar bara det som kontrollerna kan läsa i den inklistrade texten: en poäng från 100 minus ett avdrag för varje misslyckad kontroll, satt av det allvarligaste problem kontrollen hittade, och varje kritiskt problem ger F. En medelpunkt kan också vara en heuristik som ber dig kontrollera för hand, eftersom texten ensam inte visar om det är ett verkligt problem. Ett A bevisar inte att projektet är säkert, eftersom custom claims, App Check och själva datan ligger utom räckhåll.