Scrittura delle condizioni per le regole di sicurezza di Cloud Firestore

Questa guida si basa sulla guida alla strutturazione delle regole di sicurezza per mostrare come aggiungere condizioni a Cloud Firestore Security Rules. Se non hai dimestichezza con le nozioni di base di Cloud Firestore Security Rules, consulta la guida introduttiva.

L'elemento di base principale di Cloud Firestore Security Rules è la condizione. Una condizione è un'espressione booleana che determina se una determinata operazione deve essere consentita o negata. Utilizza le regole di sicurezza per scrivere condizioni che controllano l'autenticazione degli utenti, convalidano i dati in entrata o accedono ad altre parti del database.

Per l'assistenza AI, copia il prompt di seguito nel tuo agente di programmazione AI (come Gemini in Android Studio, Antigravity, Claude Code, Codex e Cursor). Puoi personalizzare il prompt e ripetere l'operazione con l'agente. Visita la pagina Skill dell'agente Firebase per informazioni dettagliate sull'installazione. 

Help me use Firebase in my app.
1. Make sure that **Firebase agent skills** are installed and updated. For Claude Code, Codex, or Cursor agents, help me install the Firebase plugin. For other agents, run `npx skills add firebase/agent-skills`. Always try to use **Firebase agent skills** for Firebase-related tasks.
2. Help me write, validate, and deploy Firebase Security Rules to protect my app's Firestore data.

Autenticazione

Uno dei pattern di regole di sicurezza più comuni è il controllo dell'accesso in base allo stato di autenticazione dell'utente. Ad esempio, la tua app potrebbe consentire solo agli utenti che hanno eseguito l'accesso di scrivere dati:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to access documents in the "cities" collection
    // only if they are authenticated.
    match /cities/{city} {
      allow read, write: if request.auth != null;
    }
  }
}

Un altro pattern comune consiste nel garantire che gli utenti possano leggere e scrivere solo i propri dati:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure the uid of the requesting user matches name of the user
    // document. The wildcard expression {userId} makes the userId variable
    // available in rules.
    match /users/{userId} {
      allow read, update, delete: if request.auth != null && request.auth.uid == userId;
      allow create: if request.auth != null;
    }
  }
}

Se la tua app utilizza Firebase Authentication o Google Cloud Identity Platform, la variabile request.auth contiene le informazioni di autenticazione per il client che richiede i dati. Per saperne di più su request.auth, consulta la documentazione di riferimento.

Convalida dei dati

Molte app archiviano le informazioni sul controllo degli accessi come campi nei documenti del database. Cloud Firestore Security Rules può consentire o negare l'accesso in modo dinamico in base ai dati del documento:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

La variabile resource fa riferimento al documento richiesto, mentre resource.data è una mappa di tutti i campi e i valori archiviati nel documento. Per saperne di più sulla variabile resource, consulta la documentazione di riferimento.

Quando scrivi i dati, potresti voler confrontare i dati in entrata con quelli esistenti. In questo caso, se il set di regole consente la scrittura in attesa, la variabile request.resource contiene lo stato futuro del documento. Per le operazioni update che modificano solo un sottoinsieme dei campi del documento, la variabile request.resource conterrà lo stato del documento in attesa dopo l'operazione. Puoi controllare i valori dei campi in request.resource per evitare aggiornamenti dei dati indesiderati o incoerenti:

service cloud.firestore {
  match /databases/{database}/documents {
    // Make sure all cities have a positive population and
    // the name is not changed
    match /cities/{city} {
      allow update: if request.resource.data.population > 0
                    && request.resource.data.name == resource.data.name;
    }
  }
}

Accedi ad altri documenti

Utilizzando le funzioni get() e exists(), le regole di sicurezza possono valutare le richieste in entrata rispetto ad altri documenti nel database. Le funzioni get() e exists() prevedono entrambe percorsi dei documenti completamente specificati. Quando utilizzi le variabili per creare percorsi per get() e exists(), devi eseguire l'escape esplicito delle variabili utilizzando la sintassi $(variable).

Nell'esempio seguente, la variabile database viene acquisita dall'istruzione match match /databases/{database}/documents e utilizzata per formare il percorso:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      // Make sure a 'users' document exists for the requesting user before
      // allowing any writes to the 'cities' collection
      allow create: if request.auth != null && exists(/databases/$(database)/documents/users/$(request.auth.uid));

      // Allow the user to delete cities if their user document has the
      // 'admin' field set to 'true'
      allow delete: if request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.admin == true;
    }
  }
}

Per le scritture, puoi utilizzare la funzione getAfter() per accedere allo stato di un documento dopo il completamento di una transazione o di un batch di scritture, ma prima del commit della transazione o del batch. Come get(), la funzione getAfter() accetta un percorso del documento completamente specificato. Puoi utilizzare getAfter() per definire insiemi di scritture che devono essere eseguite insieme come transazione o batch.

Limiti delle chiamate di accesso

Esiste un limite per le chiamate di accesso ai documenti per ogni valutazione del set di regole:

  • 10 per richieste di documenti singoli e di query.

  • 20 per letture di più documenti, transazioni e scritture in batch. Il limite precedente di 10 si applica anche a ogni operazione.

    Ad esempio, supponiamo che tu crei una richiesta di scrittura in batch con 3 operazioni di scrittura e che le tue regole di sicurezza utilizzino 2 chiamate di accesso ai documenti per convalidare ogni scrittura. In questo caso, ogni scrittura utilizza 2 delle sue 10 chiamate di accesso e la richiesta di scrittura in batch utilizza 6 delle sue 20 chiamate di accesso.

Il superamento di uno dei limiti comporta un errore di autorizzazione negata. Alcune chiamate di accesso ai documenti potrebbero essere memorizzate nella cache e le chiamate memorizzate nella cache non vengono conteggiate ai fini dei limiti.

Per una spiegazione dettagliata di come questi limiti influiscono sulle transazioni e sulle scritture in batch, consulta la guida alla protezione delle operazioni atomiche.

Chiamate di accesso e prezzi

L'utilizzo di queste funzioni esegue un'operazione di lettura nel database, il che significa che ti verrà addebitato il costo della lettura dei documenti anche se le regole rifiutano la richiesta. Per informazioni più specifiche sui dati di fatturazione, consulta Prezzi di Rules.

Funzioni personalizzate

Man mano che le regole di sicurezza diventano più complesse, potresti voler raggruppare insiemi di condizioni in funzioni che puoi riutilizzare nel tuo set di regole. Le regole di sicurezza supportano le funzioni personalizzate. La sintassi delle funzioni personalizzate è simile a JavaScript, ma le funzioni delle regole di sicurezza sono scritte in un linguaggio specifico di dominio che presenta alcune limitazioni importanti:

  • Le funzioni possono contenere una sola istruzione return. Non possono contenere logica aggiuntiva. Ad esempio, non possono eseguire loop o chiamare servizi esterni.
  • Le funzioni possono accedere automaticamente alle funzioni e alle variabili dall'ambito in cui sono definite. Ad esempio, una funzione definita nell'ambito service cloud.firestore ha accesso alla variabile resource e alle funzioni integrate come get() e exists().
  • Le funzioni possono chiamare altre funzioni, ma non possono essere ricorsive. La profondità totale dello stack di chiamate è limitata a 10.
  • Nella versione delle regole v2, le funzioni possono definire variabili utilizzando la parola chiave let. Le funzioni possono avere fino a 10 associazioni let, ma devono terminare con un'istruzione return.

Una funzione viene definita con la parola chiave function e accetta zero o più argomenti. Ad esempio, potresti voler combinare i due tipi di condizioni utilizzati negli esempi precedenti in un'unica funzione:

service cloud.firestore {
  match /databases/{database}/documents {
    // True if the user is signed in or the requested data is 'public'
    function signedInOrPublic() {
      return request.auth.uid != null || resource.data.visibility == 'public';
    }

    match /cities/{city} {
      allow read, write: if signedInOrPublic();
    }

    match /users/{user} {
      allow read, write: if signedInOrPublic();
    }
  }
}

L'utilizzo di funzioni nelle regole di sicurezza le rende più gestibili man mano che la complessità delle regole aumenta.

Le regole non sono filtri

Una volta protetti i dati e iniziata la scrittura delle query, tieni presente che le regole di sicurezza non sono filtri. Non puoi scrivere una query per tutti i documenti di una raccolta e aspettarti che le regole restituiscano solo i documenti a cui il client corrente ha l'autorizzazione di accedere.

Ad esempio, considera la seguente regola di sicurezza:

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow the user to read data if the document has the 'visibility'
    // field set to 'public'
    match /cities/{city} {
      allow read: if resource.data.visibility == 'public';
    }
  }
}

Negata: questa regola rifiuta la seguente query perché l'insieme di risultati può includere documenti in cui visibility non è public:

Web 
db.collection("cities").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
    });
});

Consentita: questa regola consente la seguente query perché la clausola where("visibility", "==", "public") garantisce che il set di risultati soddisfi la condizione della regola:

Web 
db.collection("cities").where("visibility", "==", "public").get()
    .then(function(querySnapshot) {
        querySnapshot.forEach(function(doc) {
            console.log(doc.id, " => ", doc.data());
        });
    });

Le regole di sicurezza di Rules valutano ogni query in base al suo potenziale risultato e non soddisfano la richiesta se potrebbe restituire un documento che il client non ha l'autorizzazione di leggere. Le query devono rispettare i vincoli impostati dalle regole di sicurezza. Per saperne di più sulle regole e sulle query di sicurezza, consulta Eseguire query sui dati in modo sicuro.

Passaggi successivi