Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Evitare regole non sicure

Utilizza questa guida per comprendere le vulnerabilità comuni nelle Firebase Security Rules configurazioni, esaminare e proteggere meglio le tue regole, e testare le modifiche prima di eseguirne il deployment.

Se ricevi un avviso che indica che i tuoi dati non sono protetti correttamente, esamina questi errori comuni e aggiorna le regole vulnerabili.

Accedere a Firebase Security Rules

Per visualizzare Security Rules esistenti, utilizza l'interfaccia a riga di comando Firebase o la console Firebase. Assicurati di modificare le regole utilizzando sempre lo stesso metodo per evitare di sovrascrivere accidentalmente gli aggiornamenti. Se non sai se le regole definite localmente riflettono gli aggiornamenti più recenti, la console Firebase mostra sempre la versione di cui è stato eseguito il deployment più di recente di Firebase Security Rules.

Per accedere alle regole dalla Firebase console, seleziona il tuo progetto, quindi vai a Realtime Database, Cloud Firestore o Storage. Fai clic su Regole una volta che ti trovi nel database o nel bucket di archiviazione corretto.

Per accedere alle regole dall'interfaccia a riga di comando Firebase, vai al file delle regole indicato nel file firebase.json.

Informazioni su Firebase Security Rules

Firebase Security Rules proteggono i dati da utenti malintenzionati. Quando crei un'istanza di database o un bucket Cloud Storage nella console Firebase, puoi scegliere di negare l'accesso a tutti gli utenti (modalità bloccata) o concedere l'accesso a tutti gli utenti (modalità di test). Anche se durante lo sviluppo potresti preferire una configurazione più aperta, assicurati di dedicare il tempo necessario a configurare correttamente le regole e proteggere i dati prima di eseguire il deployment dell'app.

Durante lo sviluppo dell'app e il test di configurazioni diverse per le tue regole, utilizza uno degli emulatori Firebase locali per eseguire l'app in un ambiente di sviluppo locale.

Scenari comuni con regole non sicure

Le Security Rules che potresti aver configurato per impostazione predefinita o durante lo sviluppo iniziale dell'app devono essere esaminate e aggiornate prima di eseguire il deployment dell'app. Assicurati di proteggere correttamente i dati degli utenti evitando le seguenti insidie comuni.

Accesso aperto

Quando hai configurato il progetto Firebase, potresti aver impostato le regole in modo da consentire l'accesso aperto durante lo sviluppo. Potresti pensare di essere l'unica persona a utilizzare l'app, ma se ne hai eseguito il deployment, è disponibile su internet. Se non autentichi gli utenti e non configuri le regole di sicurezza, chiunque indovini l'ID progetto può rubare, modificare o eliminare i dati.

Non consigliato: accesso in lettura e scrittura per tutti gli utenti.

Cloud Firestore

// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this ruleset in production; it allows
// anyone to overwrite your entire database.

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

Realtime Database

{
  // Allow read/write access to all users under any conditions
  // Warning: **NEVER** use this ruleset in production; it allows
  // anyone to overwrite your entire database.

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

Cloud Storage

// Anyone can read or write to the bucket, even non-users of your app.
// Because it is shared with App Engine, this will also make
// files uploaded using App Engine public.
// Warning: This rule makes every file in your Cloud Storage bucket accessible to any user.
// Apply caution before using it in production, since it means anyone
// can overwrite all your files.

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

Soluzione: regole che limitano l'accesso in lettura e scrittura.

Crea regole che abbiano senso per la gerarchia dei dati. Una delle soluzioni più comuni a questa insicurezza è la sicurezza basata sull'utente con Firebase Authentication. Scopri di più sull'autenticazione degli utenti con le regole.

Cloud Firestore

Solo proprietario dei contenuti

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow only authenticated content owners access
    match /some_collection/{document} {
      // Allow reads and deletion if the current user owns the existing document
      allow read, delete: if request.auth.uid == resource.data.author_uid;
      // 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;

    }
  }
}

Accesso pubblico e privato misto

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

Realtime Database

Solo proprietario dei contenuti

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

Accesso pubblico e privato misto

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

Cloud Storage

Solo proprietario dei contenuti

// 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.uid == userId;
    }
  }
}

Accesso pubblico e privato misto

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 per qualsiasi utente autenticato

A volte, Security Rules verificano che un utente abbia eseguito l'accesso, ma non limitano ulteriormente l'accesso in base all'autenticazione. Se una delle tue regole include auth != null, conferma di voler consentire l'accesso ai dati a qualsiasi utente che ha eseguito l'accesso.

Non consigliato: qualsiasi utente che ha eseguito l'accesso ha accesso in lettura e scrittura all'intero database.

Cloud Firestore

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

Realtime Database

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

Cloud Storage

// Only authenticated users can read or write to the bucket
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

Soluzione: limita l'accesso utilizzando le condizioni di sicurezza.

Quando verifichi l'autenticazione, potresti anche utilizzare una delle proprietà di autenticazione per limitare ulteriormente l'accesso a utenti specifici per set di dati specifici. Scopri di più sulle diverse proprietà di autenticazione.

Cloud Firestore

Accesso basato sul ruolo

service cloud.firestore {
  match /databases/{database}/documents {
    // Assign roles to all users and refine access based on user roles
    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"

     // Note: Checking for roles in your database using `get` (as in the code
     // above) or `exists` carry standard charges for read operations.
    }
  }
}

Accesso basato su attributi

// Give each user in your database a particular attribute
// and set it to true/false
// Then, use that attribute to grant access to subsets of data
// For example, an "administrator" attribute set
// to "true" grants write access to data

service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow write: if get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
      allow read: true;
    }
  }
}

Accesso pubblico e privato misto

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 write: if request.auth.uid == request.resource.data.author_uid
    }
  }
}

Realtime Database

Solo proprietario dei contenuti

{
  "rules": {
    "some_path": {
      "$uid": {
        // Allow only authenticated content owners access to their data
        ".read": "auth.uid === $uid",
        ".write": "auth.uid === $uid"
      }
    }
  }
}

Accesso delimitato dal percorso

{
  "rules": {
    "some_path/$uid": {
      ".write": "auth.uid === $uid",
      // Create a "public" subpath in your dataset
      "public": {
        ".read": true
        // or ".read": "auth.uid !== null"
      },
      // Create a "private" subpath in your dataset
      "private": {
        ".read": "auth.uid === $uid"
      }
    }
  }
}

Accesso pubblico e privato misto

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

Cloud Storage

Accesso basato sul gruppo

// Allow reads if the group ID in your token matches the file metadata `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;
}

Solo proprietario dei contenuti

// 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.uid == userId;
    }
  }
}

Accesso pubblico e privato misto

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

(Realtime Database) Regole ereditate in modo errato

Realtime Database Security Rules vengono applicate a cascata, con le regole nei percorsi principali meno profondi che sostituiscono le regole nei nodi secondari più profondi. Quando scrivi una regola in un nodo secondario, ricorda che può solo concedere privilegi aggiuntivi. Non puoi perfezionare o revocare l'accesso ai dati in un percorso più profondo del database.

Non consigliato: perfezionamento delle regole nei percorsi secondari

{
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
        }
     }
  }
}

Soluzione: scrivi regole ampie nei percorsi principali e concedi privilegi più specifici nei percorsi secondari Se le tue esigenze di accesso ai dati richiedono una maggiore granularità, mantieni le regole granulari. Scopri di più sulle regole di sicurezza di Realtime Database a cascata in sintassi di base delle regole di sicurezza di Realtime Database.Realtime Database Security RulesRealtime Database Security Rules

Accesso chiuso

Durante lo sviluppo dell'app, un altro approccio comune consiste nel mantenere i dati bloccati. In genere, ciò significa che hai chiuso l'accesso in lettura e scrittura a tutti gli utenti, come segue:

Cloud Firestore

// Deny read/write access to all users under any conditions
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Realtime Database

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

Cloud Storage

// Access to files through Cloud Storage is completely disallowed.
// Files may still be accessible through App Engine or Google Cloud Storage APIs.

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

Gli SDK Admin Firebase e Cloud Functions possono comunque accedere al database. Utilizza queste regole quando intendi utilizzare Cloud Firestore o Realtime Database come backend solo server in combinazione con l'SDK Admin Firebase. Sebbene sia sicuro, devi verificare che i client dell'app possano recuperare correttamente i dati.

Scopri di più su Cloud Firestore Security Rules e sul loro funzionamento in Guida introduttiva a Cloud Firestore Security Rules.

Testare il tuo Cloud Firestore Security Rules

Per controllare il comportamento dell'app e verificare le configurazioni Cloud Firestore Security Rules, utilizza l'emulatore Firebase. Utilizza l'Cloud Firestore emulatore per eseguire e automatizzare i test delle unità in un ambiente locale prima di eseguire il deployment di eventuali modifiche.

Per convalidare rapidamente Firebase Security Rules nella console Firebase, utilizza il simulatore di regole di Firebase.

Evitare regole non sicure Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Accedere a Firebase Security Rules

Informazioni su Firebase Security Rules

Scenari comuni con regole non sicure

Accesso aperto

Cloud Firestore

Realtime Database

Cloud Storage

Cloud Firestore

Solo proprietario dei contenuti

Accesso pubblico e privato misto

Realtime Database

Solo proprietario dei contenuti

Accesso pubblico e privato misto

Cloud Storage

Solo proprietario dei contenuti

Accesso pubblico e privato misto

Accesso per qualsiasi utente autenticato

Cloud Firestore

Realtime Database

Cloud Storage

Cloud Firestore

Accesso basato sul ruolo

Accesso basato su attributi

Accesso pubblico e privato misto

Realtime Database

Solo proprietario dei contenuti

Accesso delimitato dal percorso

Accesso pubblico e privato misto

Cloud Storage

Accesso basato sul gruppo

Solo proprietario dei contenuti

Accesso pubblico e privato misto

(Realtime Database) Regole ereditate in modo errato

Accesso chiuso

Cloud Firestore

Realtime Database

Cloud Storage

Testare il tuo Cloud Firestore Security Rules

Evitare regole non sicure