Regole di sicurezza di base

Firebase Security Rules ti consentono di controllare l'accesso ai dati archiviati. La sintassi delle regole flessibili ti consente di creare regole che corrispondono a qualsiasi cosa, da tutte le scritture all'intero database alle operazioni su un documento specifico.

Questa guida descrive alcuni dei casi d'uso più semplici che potresti voler implementare durante la configurazione dell'app e la protezione dei dati. Tuttavia, prima di iniziare a scrivere regole, ti consigliamo di scoprire di più sul linguaggio in cui sono scritte e sul loro comportamento.

Per accedere alle regole e aggiornarle, segui i passaggi descritti in Gestire e implementare Firebase Security Rules.

Regole predefinite: modalità di blocco

Quando crei un database o un'istanza di archiviazione nella console Firebase, scegli se Firebase Security Rules limitare l'accesso ai tuoi dati (modalità bloccata) o consentire l'accesso a chiunque (modalità di 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.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

{
  "rules": {
    ".read": false,
    ".write": false
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

Regole dell'ambiente di sviluppo

Mentre lavori alla tua app, potresti voler accedere ai tuoi dati in modo relativamente aperto o senza restrizioni. Assicurati solo di aggiornare Rules prima di eseguire il deployment dell'app in produzione. Ricorda inoltre che se esegui il deployment dell'app, questa è accessibile pubblicamente, anche se non l'hai avviata.

Ricorda che Firebase consente ai client l'accesso diretto ai tuoi dati e che le Firebase Security Rules sono l'unica protezione che blocca l'accesso per gli utenti malintenzionati. La definizione delle regole separatamente dalla logica del prodotto presenta una serie di vantaggi: i client non sono responsabili dell'applicazione della sicurezza, le implementazioni piene di bug non compromettono i tuoi dati e, soprattutto, non fai affidamento su un server intermediario per proteggere i dati dal mondo.

Tutti gli utenti autenticati

Anche se non consigliamo di lasciare i dati accessibili a qualsiasi utente che ha eseguito l'accesso, potrebbe essere utile impostare l'accesso a qualsiasi utente autenticato durante lo sviluppo dell'app.

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}

{
  "rules": {
    "some_path": {
      ".read": "auth.uid !== null",
      ".write": "auth.uid !== null"
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    match /some_folder/{fileName} {
      allow read, write: if request.auth != null;
    }
  }
}

Regole pronte per la produzione

Mentre ti prepari a eseguire il deployment dell'app, assicurati che i tuoi dati siano protetti e che l'accesso sia concesso correttamente ai tuoi utenti. Utilizza Authentication per configurare l'accesso basato sugli utenti e leggere direttamente dal database per configurare l'accesso basato sui dati.

Ti consigliamo di scrivere le regole mentre strutturi i dati, poiché il modo in cui le configuri influisce sulla limitazione dell'accesso ai dati in percorsi diversi.

Accesso solo per i proprietari dei contenuti

Queste regole limitano l'accesso solo al proprietario autenticato dei contenuti. I dati sono leggibili e scrivibili solo da un utente e il percorso dei dati contiene l'ID utente.

Quando funziona questa regola: questa regola funziona bene se i dati sono isolati per utente, ovvero se l'unico utente che deve accedere ai dati è lo stesso che li ha creati.

Quando questo insieme di regole non funziona: questo insieme di regole non funziona quando più utenti devono scrivere o leggere gli stessi dati: gli utenti sovrascriveranno i dati o non potranno accedere ai dati che hanno creato.

Per configurare questa regola: crea una regola che confermi che l'utente che richiede l'accesso in lettura o scrittura ai dati è l'utente proprietario di questi dati.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{userId}/{document} {
      allow read, write: if request.auth != null && request.auth.uid == userId
    }
  }
}

{
  "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"
      }
    }
  }
}

// Grants a user access to a node matching their user ID
service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Accesso pubblico e privato misto

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 dei contenuti autenticato.

Quando funziona questa regola: questa regola è adatta alle app che richiedono elementi leggibili pubblicamente, ma devono limitare l'accesso in modifica ai proprietari di questi elementi. Ad esempio, un'app di chat o un blog.

Quando questa regola non funziona:come la regola solo per i proprietari dei contenuti, questo insieme di regole non funziona quando più utenti devono modificare gli stessi dati. Gli utenti alla fine sovrascriveranno i dati degli altri.

Per configurare questa regola: crea una regola che consenta l'accesso in lettura a tutti gli utenti (o a tutti gli utenti autenticati) e che confermi che l'utente che scrive i dati è il proprietario.

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow public read access, but only content owners can write
    match /some_collection/{document} {
      // Allow public reads
      allow read: if true
      // Allow creation if the current user owns the new document
      allow create: if request.auth.uid == request.resource.data.author_uid;
      // Allow updates by the owner, and prevent change of ownership
      allow update: if request.auth.uid == request.resource.data.author_uid
                    && request.auth.uid == resource.data.author_uid;
      // Allow deletion if the current user owns the existing document
      allow delete: if request.auth.uid == resource.data.author_uid;
    }
  }
}

{
// 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"
      }
    }
  }
}

service firebase.storage {
  match /b/{bucket}/o {
    // Files look like: "user/<UID>/file.txt"
    match /user/{userId}/{fileName} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

Accesso basato su attributi e ruoli

Affinché questa regola funzioni, devi definire e assegnare attributi agli utenti nei tuoi dati. Firebase Security Rules controlla la richiesta rispetto ai dati del database o ai metadati del file per confermare o negare l'accesso.

Quando funziona questa regola: se assegni un ruolo agli utenti, questa regola ti consente di limitare l'accesso in base ai ruoli o a gruppi specifici di utenti. Ad esempio, se memorizzi i voti, puoi assegnare diversi livelli di accesso al gruppo "studenti" (solo lettura dei contenuti), al gruppo "insegnanti" (lettura e scrittura nella loro materia) e al gruppo "presidi" (lettura di tutti i contenuti).

Quando questa regola non funziona: in Realtime Database e Cloud Storage, le regole non possono utilizzare il metodo get() che le regole Cloud Firestore possono incorporare. Di conseguenza, devi strutturare i metadati del database o del file in modo che riflettano gli attributi che utilizzi nelle regole.

Per configurare questa regola:in Cloud Firestore, includi un campo nei documenti degli utenti che puoi leggere, quindi struttura la regola in modo che legga quel campo e conceda l'accesso in modo condizionale. In Realtime Database, crea un percorso dei dati che definisca gli utenti della tua app e assegni loro un ruolo in un nodo secondario.

Puoi anche configurare rivendicazioni personalizzate in Authentication e poi recuperare queste informazioni dalla variabile auth.token in qualsiasi Firebase Security Rules.

Attributi e ruoli definiti dai dati

Queste regole funzionano solo in Cloud Firestore e Realtime Database.

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"
   }
  }
}

{
  "rules": {
    "some_path": {
      "${subpath}": {
        //
        ".write": "root.child('users').child(auth.uid).child('role').val() === 'admin'",
        ".read": true
      }
    }
  }
}

Attributi e ruoli delle rivendicazioni personalizzate

Per implementare queste regole, configura rivendicazioni personalizzate in Firebase Authentication e poi utilizza le rivendicazioni nelle regole.

service cloud.firestore {
  match /databases/{database}/documents {
    // For attribute-based access control, check for an administrator 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";
   }
  }
}

{
  "rules": {
    "some_path": {
      "$uid": {
        // Create a custom claim for each role or group
        // you want to use
        ".write": "auth.uid !== null && auth.token.writer === true",
        ".read": "auth.uid !== null && auth.token.reader === true"
      }
    }
  }
}

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 del tenancy

Per implementare queste regole, configura la multitenancy in Google Cloud Identity Platform (GCIP) e poi utilizza il tenant nelle regole. Gli esempi seguenti consentono le scritture da parte di un utente in un tenant specifico, ad esempio tenant2-m6tyz

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;
  }
}

{
  "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
      }
    }
  }
}

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;
  }
}