Le regole di sicurezza Firebase ti consentono di controllare l'accesso ai tuoi dati archiviati. La sintassi flessibile delle regole significa che puoi creare regole che corrispondono a qualsiasi cosa, da tutte le scritture sull'intero database alle operazioni su un documento specifico.
Questa guida descrive alcuni dei casi d'uso più basilari che potresti voler implementare durante la configurazione della tua app e la salvaguardia dei tuoi dati. Tuttavia, prima di iniziare a scrivere le regole, potresti voler saperne di più sulla lingua in cui sono scritte e sul loro comportamento .
Per accedere e aggiornare le tue regole, segui i passaggi descritti in Gestire e distribuire le regole di sicurezza Firebase .
Regole predefinite: modalità bloccata
Quando crei un database o un'istanza di archiviazione nella console Firebase, scegli se le regole di sicurezza Firebase limitano l'accesso ai tuoi dati ( modalità bloccata ) o consentono a chiunque l'accesso ( modalità test ). In Cloud Firestore e Realtime Database, le regole predefinite per la modalità bloccata negano l'accesso a tutti gli utenti. In Cloud Storage, solo gli utenti autenticati possono accedere ai bucket di archiviazione.
Cloud Fire Store
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if false;
}
}
}
Banca dati in tempo reale
{
"rules": {
".read": false,
".write": false
}
}
Archiviazione nel cloud
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Regole dell'ambiente di sviluppo
Mentre lavori sulla tua app, potresti desiderare un accesso relativamente aperto e illimitato ai tuoi dati. Assicurati solo di aggiornare le tue regole prima di distribuire la tua app in produzione. Ricorda inoltre che se distribuisci la tua app, sarà accessibile pubblicamente, anche se non l'hai avviata .
Ricorda che Firebase consente ai client l'accesso diretto ai tuoi dati e che le regole di sicurezza Firebase sono l'unica protezione che blocca l'accesso per utenti malintenzionati. Definire le regole separatamente dalla logica del prodotto presenta una serie di vantaggi: i clienti non sono responsabili dell'applicazione della sicurezza, le implementazioni difettose non comprometteranno i tuoi dati e, cosa più importante, non ti affidi a un server intermedio per proteggere i dati dal mondo.
Tutti gli utenti autenticati
Anche se non consigliamo di lasciare i tuoi dati accessibili a qualsiasi utente che ha effettuato l'accesso, potrebbe essere utile impostare l'accesso per qualsiasi utente autenticato mentre sviluppi la tua app.
Cloud Fire Store
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if request.auth != null;
}
}
}
Banca dati in tempo reale
{
"rules": {
".read": "auth.uid !== null",
".write": "auth.uid !== null"
}
}
Archiviazione nel cloud
service firebase.storage {
match /b/{bucket}/o {
match /{allPaths=**} {
allow read, write: if request.auth != null;
}
}
}
Regole pronte per la produzione
Mentre ti prepari a distribuire la tua app, assicurati che i tuoi dati siano protetti e che l'accesso sia concesso correttamente ai tuoi utenti. Sfrutta l'autenticazione per impostare l'accesso basato sull'utente e leggi direttamente dal tuo database per impostare l'accesso basato sui dati.
Valuta la possibilità di scrivere regole mentre strutturi i dati, poiché il modo in cui imposti le regole influisce sul modo in cui limiti l'accesso ai dati su percorsi diversi.
Accesso riservato al proprietario dei contenuti
Queste regole limitano l'accesso solo al proprietario autenticato del contenuto. I dati sono leggibili e scrivibili solo da un utente e il percorso dei dati contiene l'ID dell'utente.
Quando questa regola funziona: questa regola funziona bene se i dati vengono isolati per utente, se l'unico utente che deve accedere ai dati è lo stesso utente che ha creato i dati.
Quando questa regola non funziona: questo set di regole non funziona quando più utenti devono scrivere o leggere gli stessi dati: gli utenti sovrascriveranno i dati o non saranno in grado di accedere ai dati che hanno creato.
Per impostare questa regola: Crea una regola che confermi che l'utente che richiede l'accesso per leggere o scrivere i dati sia l'utente che possiede tali dati.
Cloud Fire Store
service cloud.firestore {
match /databases/{database}/documents {
// Allow only authenticated content owners access
match /some_collection/{userId}/{documents=**} {
allow read, write: if request.auth != null && request.auth.uid == userId
}
}
}
Banca dati in tempo reale
{
"rules": {
"some_path": {
"$uid": {
// Allow only authenticated content owners access to their data
".read": "auth !== null && auth.uid === $uid",
".write": "auth !== null && auth.uid === $uid"
}
}
}
}
Archiviazione nel cloud
// Grants a user access to a node matching their user ID
service firebase.storage {
match /b/{bucket}/o {
// Files look like: "user/<UID>/path/to/file.txt"
match /user/{userId}/{allPaths=**} {
allow read, write: if request.auth != null && request.auth.uid == userId;
}
}
}
Accesso misto pubblico e privato
Questa regola consente a chiunque di leggere un set di dati, ma limita la possibilità di creare o modificare i dati in un determinato percorso solo al proprietario del contenuto autenticato.
Quando funziona questa regola: questa regola funziona bene per le app che richiedono elementi leggibili pubblicamente, ma devono limitare l'accesso in modifica ai proprietari di tali elementi. Ad esempio, un'app di chat o un blog.
Quando questa regola non funziona: come la regola riservata al proprietario del contenuto, questo insieme di regole non funziona quando più utenti devono modificare gli stessi dati. Gli utenti alla fine sovrascriveranno i dati degli altri.
Per impostare questa regola: crea una regola che consenta l'accesso in lettura a tutti gli utenti (o a tutti gli utenti autenticati) e confermi che l'utente che scrive i dati sia il proprietario.
Cloud Fire Store
service cloud.firestore {
match /databases/{database}/documents {
// Allow public read access, but only content owners can write
match /some_collection/{document} {
allow read: if true
allow create: if request.auth.uid == request.resource.data.author_uid;
allow update, delete: if request.auth.uid == resource.data.author_uid;
}
}
}
Banca dati in tempo reale
{
// Allow anyone to read data, but only authenticated content owners can
// make changes to their data
"rules": {
"some_path": {
"$uid": {
".read": true,
// or ".read": "auth.uid !== null" for only authenticated users
".write": "auth.uid === $uid"
}
}
}
}
Archiviazione nel cloud
service firebase.storage {
match /b/{bucket}/o {
// Files look like: "user/<UID>/path/to/file.txt"
match /user/{userId}/{allPaths=**} {
allow read;
allow write: if request.auth.uid == userId;
}
}
}
Accesso basato su attributi e basato su ruoli
Affinché queste regole funzionino, devi definire e assegnare attributi agli utenti nei tuoi dati. Le regole di sicurezza Firebase confrontano la richiesta con i dati del database o con i metadati del file per confermare o negare l'accesso.
Quando funziona questa regola: se assegni un ruolo agli utenti, questa regola semplifica la limitazione dell'accesso in base ai ruoli o a gruppi specifici di utenti. Ad esempio, se stessi memorizzando i voti, potresti assegnare diversi livelli di accesso al gruppo "studenti" (solo lettura del loro contenuto), al gruppo "docenti" (lettura e scrittura della materia) e al gruppo "preside" (lettura tutti i contenuti).
Quando questa regola non funziona: in Realtime Database e Cloud Storage, le tue regole non possono sfruttare il metodo get() che le regole di Cloud Firestore possono incorporare. Di conseguenza, devi strutturare il tuo database o i metadati del file in modo da riflettere gli attributi che stai utilizzando nelle tue regole.
Per impostare questa regola: in Cloud Firestore, includi un campo che puoi leggere nei documenti degli utenti, quindi struttura la regola per leggere quel campo e concedere l'accesso in modo condizionale. In Realtime Database, crea un percorso dati che definisca gli utenti della tua app e conceda loro un ruolo in un nodo figlio.
Puoi anche impostare attestazioni personalizzate in Autenticazione e quindi recuperare tali informazioni dalla variabile auth.token in qualsiasi regola di sicurezza Firebase.
Attributi e ruoli definiti dai dati
Queste regole funzionano solo in Cloud Firestore e Realtime Database.
Cloud Fire Store
Ricorda che ogni volta che le tue regole includono una lettura, come le regole di seguito, ti verrà addebitata un'operazione di lettura in Cloud Firestore.
service cloud.firestore {
match /databases/{database}/documents {
// For attribute-based access control, Check a boolean `admin` attribute
allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
allow read: true;
// Alterntatively, for role-based access, assign specific roles to users
match /some_collection/{document} {
allow read: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Writer"
}
}
}
Banca dati in tempo reale
{
"rules": {
"some_path": {
"${subpath}": {
//
".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
".read": true
}
}
}
}
Attributi e ruoli di attestazione personalizzata
Per implementare queste regole, imposta attestazioni personalizzate in Firebase Authentication e quindi sfrutta le attestazioni nelle tue regole.
Cloud Fire Store
service cloud.firestore {
match /databases/{database}/documents {
// For attribute-based access control, check for an admin claim
allow write: if request.auth.token.admin == true;
allow read: true;
// Alterntatively, for role-based access, assign specific roles to users
match /some_collection/{document} {
allow read: if request.auth.token.reader == "true";
allow write: if request.auth.token.writer == "true";
}
}
}
Banca dati in tempo reale
{
"rules": {
"some_path": {
"$uid": {
// Create a custom claim for each role or group
// you want to leverage
".write": "auth.uid !== null && auth.token.writer === true",
".read": "auth.uid !== null && auth.token.reader === true"
}
}
}
}
Archiviazione nel cloud
service firebase.storage {
// Allow reads if the group ID in your token matches the file metadata's `owner` property
// Allow writes if the group ID is in the user's custom token
match /files/{groupId}/{fileName} {
allow read: if resource.metadata.owner == request.auth.token.groupId;
allow write: if request.auth.token.groupId == groupId;
}
}
Attributi di locazione
Per implementare queste regole, configura la multi-tenant in Google Cloud Identity Platform (GCIP) e quindi sfrutta il tenant nelle tue regole. Gli esempi seguenti consentono le scritture da parte di un utente in un tenant specifico, ad esempio tenant2-m6tyz
Cloud Fire Store
service cloud.firestore {
match /databases/{database}/documents {
// For tenant-based access control, check for a tenantID
allow write: if request.auth.token.firebase.tenant == 'tenant2-m6tyz';
allow read: true;
}
}
Banca dati in tempo reale
{
"rules": {
"some_path": {
"$uid": {
// Only allow reads and writes if user belongs to a specific tenant
".write": "auth.uid !== null && auth.token.firebase.tenant === 'tenant2-m6tyz'",
".read": "auth.uid !== null
}
}
}
}
Archiviazione nel cloud
service firebase.storage {
// Only allow reads and writes if user belongs to a specific tenant
match /files/{tenantId}/{fileName} {
allow read: if request.auth != null;
allow write: if request.auth.token.firebase.tenant == tenantId;
}
}