Cómo funcionan las reglas de seguridad

Tienda de fuego en la nube

Estructura basica

Las reglas de seguridad de Firebase en Cloud Firestore y Cloud Storage utilizan la siguiente estructura y sintaxis:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Es importante comprender los siguientes conceptos clave al crear las reglas:

• Solicitud: el método o métodos invocados en la declaración allow . Estos son métodos que estás permitiendo ejecutar. Los métodos estándar son: get , list , create , update y delete . Los métodos convenientes read y write permiten un amplio acceso de lectura y escritura en la base de datos o ruta de almacenamiento especificada.
• Ruta: la base de datos o la ubicación de almacenamiento, representada como una ruta URI.
• Regla: la declaración allow , que incluye una condición que permite una solicitud si se evalúa como verdadera.

Reglas de seguridad versión 2

A partir de mayo de 2019, la versión 2 de las reglas de seguridad de Firebase ya está disponible. La versión 2 de las reglas cambia el comportamiento de los comodines recursivos {name=**} . Debe utilizar la versión 2 si planea utilizar consultas de grupos de recopilación . Debes optar por la versión 2 creando rules_version = '2'; la primera línea en sus reglas de seguridad:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

Caminos coincidentes

Todas las declaraciones de coincidencias deben apuntar a documentos, no a colecciones. Una declaración de coincidencia puede apuntar a un documento específico, como en match /cities/SF o usar comodines para apuntar a cualquier documento en la ruta especificada, como en match /cities/{city} .

En el ejemplo anterior, la declaración de coincidencia utiliza la sintaxis comodín {city} . Esto significa que la regla se aplica a cualquier documento de la colección cities , como /cities/SF o /cities/NYC . Cuando se evalúan las expresiones allow en la declaración de coincidencia, la variable city se resolverá en el nombre del documento de la ciudad, como SF o NYC .

Subcolecciones coincidentes

Los datos en Cloud Firestore están organizados en colecciones de documentos y cada documento puede ampliar la jerarquía a través de subcolecciones. Es importante comprender cómo interactúan las reglas de seguridad con los datos jerárquicos.

Considere la situación en la que cada documento de la colección cities contiene una subcolección landmarks . Las reglas de seguridad se aplican solo en la ruta coincidente, por lo que los controles de acceso definidos en la colección cities no se aplican a la subcolección de landmarks . En su lugar, escriba reglas explícitas para controlar el acceso a las subcolecciones:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      allow read, write: if <condition>;

      // Explicitly define rules for the 'landmarks' subcollection
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

Al anidar declaraciones match , la ruta de la declaración match interna siempre es relativa a la ruta de la declaración match externa. Por tanto, los siguientes conjuntos de reglas son equivalentes:

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city} {
      match /landmarks/{landmark} {
        allow read, write: if <condition>;
      }
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    match /cities/{city}/landmarks/{landmark} {
      allow read, write: if <condition>;
    }
  }
}

comodines recursivos

Si desea que las reglas se apliquen a una jerarquía arbitrariamente profunda, utilice la sintaxis comodín recursiva, {name=**} :

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

Cuando se utiliza la sintaxis recursiva de comodín, la variable comodín contendrá todo el segmento de ruta coincidente, incluso si el documento está ubicado en una subcolección profundamente anidada. Por ejemplo, las reglas enumeradas anteriormente coincidirían con un documento ubicado en /cities/SF/landmarks/coit_tower y el valor de la variable document sería SF/landmarks/coit_tower .

Sin embargo, tenga en cuenta que el comportamiento de los comodines recursivos depende de la versión de las reglas.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the cities collection as well as any document
    // in a subcollection.
    match /cities/{city}/{document=**} {
      allow read, write: if <condition>;
    }
  }
}

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the songs collection group
    match /{path=**}/songs/{song} {
      allow read, write: if <condition>;
    }
  }
}

Si utiliza consultas de grupos de recopilación , debe utilizar la versión 2; consulte Cómo proteger consultas de grupos de recopilación .

Declaraciones de coincidencias superpuestas

Es posible que un documento coincida con más de una declaración match . En el caso de que varias expresiones allow coincidan con una solicitud, se permite el acceso si alguna de las condiciones es true :

service cloud.firestore {
  match /databases/{database}/documents {
    // Matches any document in the 'cities' collection.
    match /cities/{city} {
      allow read, write: if false;
    }

    // Matches any document in the 'cities' collection or subcollections.
    match /cities/{document=**} {
      allow read, write: if true;
    }
  }
}

En el ejemplo anterior, se permitirán todas las lecturas y escrituras en la colección cities porque la segunda regla siempre es true , aunque la primera regla siempre es false .

Límites de las reglas de seguridad

Al trabajar con reglas de seguridad, tenga en cuenta los siguientes límites:

Almacenamiento en la nube

Estructura basica

Las reglas de seguridad de Firebase en Cloud Firestore y Cloud Storage utilizan la siguiente estructura y sintaxis:

service <<name>> {
  // Match the resource path.
  match <<path>> {
    // Allow the request if the following conditions are true.
    allow <<methods>> : if <<condition>>
  }
}

Es importante comprender los siguientes conceptos clave al crear las reglas:

• Solicitud: el método o métodos invocados en la declaración allow . Estos son métodos que estás permitiendo ejecutar. Los métodos estándar son: get , list , create , update y delete . Los métodos convenientes read y write permiten un amplio acceso de lectura y escritura en la base de datos o ruta de almacenamiento especificada.
• Ruta: la base de datos o la ubicación de almacenamiento, representada como una ruta URI.
• Regla: la declaración allow , que incluye una condición que permite una solicitud si se evalúa como verdadera.

Caminos coincidentes

Las reglas de seguridad de Cloud Storage match las rutas de archivo utilizadas para acceder a los archivos en Cloud Storage. Las reglas pueden match rutas exactas o rutas comodín, y las reglas también se pueden anidar. Si ninguna regla de coincidencia permite un método de solicitud o la condición se evalúa como false , se rechaza la solicitud.

Coincidencias exactas

// Exact match for "images/profilePhoto.png"
match /images/profilePhoto.png {
  allow write: if <condition>;
}

// Exact match for "images/croppedProfilePhoto.png"
match /images/croppedProfilePhoto.png {
  allow write: if <other_condition>;
}

Coincidencias anidadas

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/profilePhoto.png"
  match /profilePhoto.png {
    allow write: if <condition>;
  }

  // Exact match for "images/croppedProfilePhoto.png"
  match /croppedProfilePhoto.png {
    allow write: if <other_condition>;
  }
}

Coincidencias con comodines

También se pueden utilizar reglas para match un patrón mediante comodines. Un comodín es una variable con nombre que representa una sola cadena como profilePhoto.png o múltiples segmentos de ruta, como images/profilePhoto.png .

Un comodín se crea agregando llaves alrededor del nombre del comodín, como {string} . Se puede declarar un comodín de múltiples segmentos agregando =** al nombre del comodín, como {path=**} :

// Partial match for files that start with "images"
match /images {
  // Exact match for "images/*"
  // e.g. images/profilePhoto.png is matched
  match /{imageId} {
    // This rule only matches a single path segment (*)
    // imageId is a string that contains the specific segment matched
    allow read: if <condition>;
  }

  // Exact match for "images/**"
  // e.g. images/users/user:12345/profilePhoto.png is matched
  // images/profilePhoto.png is also matched!
  match /{allImages=**} {
    // This rule matches one or more path segments (**)
    // allImages is a path that contains all segments matched
    allow read: if <other_condition>;
  }
}

Si varias reglas coinciden con un archivo, el resultado es el OR del resultado de todas las evaluaciones de reglas. Es decir, si alguna regla que coincida con el archivo se evalúa como true , el resultado es true .

En las reglas anteriores, el archivo "images/profilePhoto.png" se puede leer si condition u other_condition se evalúa como verdadera, mientras que el archivo "images/users/user:12345/profilePhoto.png" solo está sujeto al resultado de other_condition .

Se puede hacer referencia a una variable comodín desde la match , proporcionando nombre de archivo o autorización de ruta:

// Another way to restrict the name of a file
match /images/{imageId} {
  allow read: if imageId == "profilePhoto.png";
}

Las reglas de seguridad de Cloud Storage no se aplican en cascada y solo se evalúan cuando la ruta de la solicitud coincide con una ruta con las reglas especificadas.

Solicitar evaluación

Las cargas, descargas, cambios de metadatos y eliminaciones se evalúan mediante la request enviada a Cloud Storage. La variable request contiene la ruta del archivo donde se realiza la solicitud, la hora en que se recibe la solicitud y el nuevo valor resource si la solicitud es una escritura. También se incluyen los encabezados HTTP y el estado de autenticación.

El objeto request también contiene la identificación única del usuario y la carga útil de autenticación de Firebase en el objeto request.auth , que se explicará con más detalle en la sección Autenticación de los documentos.

Una lista completa de propiedades en el objeto request está disponible a continuación:

Evaluación de recursos

Al evaluar las reglas, es posible que también desee evaluar los metadatos del archivo que se carga, descarga, modifica o elimina. Esto le permite crear reglas complejas y poderosas que hacen cosas como permitir que solo se carguen archivos con ciertos tipos de contenido o que solo se eliminen archivos mayores a un cierto tamaño.

Las reglas de seguridad de Firebase para Cloud Storage proporcionan metadatos de archivos en el objeto resource , que contiene pares clave/valor de los metadatos que aparecen en un objeto de Cloud Storage. Estas propiedades se pueden inspeccionar en solicitudes de read o write para garantizar la integridad de los datos.

En solicitudes write (como cargas, actualizaciones de metadatos y eliminaciones), además del objeto resource , que contiene metadatos del archivo que existe actualmente en la ruta de la solicitud, también tiene la posibilidad de utilizar el objeto request.resource , que contiene un subconjunto de los metadatos del archivo que se escribirán si se permite la escritura. Puede utilizar estos dos valores para garantizar la integridad de los datos o imponer restricciones de la aplicación, como el tipo o el tamaño del archivo.

Una lista completa de propiedades en el objeto resource está disponible a continuación:

request.resource contiene todos estos con la excepción de generation , metageneration , etag , timeCreated y updated .

Límites de las reglas de seguridad

Al trabajar con reglas de seguridad, tenga en cuenta los siguientes límites:

Ejemplo completo

Al reunirlo todo, puede crear un ejemplo completo de reglas para una solución de almacenamiento de imágenes:

service firebase.storage {
 match /b/{bucket}/o {
   match /images {
     // Cascade read to any image type at any path
     match /{allImages=**} {
       allow read;
     }

     // Allow write files to the path "images/*", subject to the constraints:
     // 1) File is less than 5MB
     // 2) Content type is an image
     // 3) Uploaded content type matches existing content type
     // 4) File name (stored in imageId wildcard variable) is less than 32 characters
     match /{imageId} {
       allow write: if request.resource.size < 5 * 1024 * 1024
                    && request.resource.contentType.matches('image/.*')
                    && request.resource.contentType == resource.contentType
                    && imageId.size() < 32
     }
   }
 }
}

Base de datos en tiempo real

Estructura basica

En Realtime Database, las reglas de seguridad de Firebase consisten en expresiones similares a JavaScript contenidas en un documento JSON.

Utilizan la siguiente sintaxis:

{
  "rules": {
    "<<path>>": {
    // Allow the request if the condition for each method is true.
      ".read": <<condition>>,
      ".write": <<condition>>,
      ".validate": <<condition>>
    }
  }
}

Hay tres elementos básicos en la regla:

• Ruta: la ubicación de la base de datos. Esto refleja la estructura JSON de su base de datos.
• Solicitud: estos son los métodos que utiliza la regla para otorgar acceso. Las reglas read y write otorgan un amplio acceso de lectura y escritura, mientras que las reglas validate actúan como una verificación secundaria para otorgar acceso según los datos entrantes o existentes.
• Condición: la condición que permite una solicitud si se evalúa como verdadera.

Cómo se aplican las reglas a los caminos

En Realtime Database, las reglas se aplican de forma atómica, lo que significa que las reglas en los nodos principales de nivel superior anulan las reglas en los nodos secundarios más granulares y las reglas en un nodo más profundo no pueden otorgar acceso a una ruta principal. No puede refinar ni revocar el acceso a una ruta más profunda en la estructura de su base de datos si ya lo ha otorgado para una de las rutas principales.

Considere las siguientes reglas:

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

Esta estructura de seguridad permite leer /bar/ siempre que /foo/ contenga un baz secundario con valor true . La regla ".read": false en /foo/bar/ no tiene ningún efecto aquí, ya que el acceso no puede ser revocado por una ruta secundaria.

Si bien puede no parecer inmediatamente intuitivo, esta es una parte poderosa del lenguaje de reglas y permite implementar privilegios de acceso muy complejos con un mínimo esfuerzo. Esto es particularmente útil para la seguridad basada en usuarios .

Sin embargo, las reglas .validate no se ejecutan en cascada. Se deben cumplir todas las reglas de validación en todos los niveles de la jerarquía para que se permita una escritura.

Además, debido a que las reglas no se aplican a una ruta principal, la operación de lectura o escritura falla si no hay una regla en la ubicación solicitada o en una ubicación principal que otorgue acceso. Incluso si se puede acceder a todas las rutas secundarias afectadas, la lectura en la ubicación principal fallará por completo. Considere esta estructura:

{
  "rules": {
    "records": {
      "rec1": {
        ".read": true
      },
      "rec2": {
        ".read": false
      }
    }
  }
}

Sin entender que las reglas se evalúan atómicamente, podría parecer que recuperar la ruta /records/ devolvería rec1 pero no rec2 . El resultado real, sin embargo, es un error:

var db = firebase.database();
db.ref("records").once("value", function(snap) {
  // success method is not called
}, function(err) {
  // error callback triggered with PERMISSION_DENIED
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[_ref child:@"records"] observeSingleEventOfType:FIRDataEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
  // success block is not called
} withCancelBlock:^(NSError * _Nonnull error) {
  // cancel block triggered with PERMISSION_DENIED
}];

var ref = FIRDatabase.database().reference()
ref.child("records").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // success block is not called
}, withCancelBlock: { error in
    // cancel block triggered with PERMISSION_DENIED
})

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // success method is not called
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback triggered with PERMISSION_DENIED
  });
});

curl https://docs-examples.firebaseio.com/rest/records/
# response returns a PERMISSION_DENIED error

Dado que la operación de lectura en /records/ es atómica y no existe una regla de lectura que otorgue acceso a todos los datos en /records/ , esto generará un error PERMISSION_DENIED . Si evaluamos esta regla en el simulador de seguridad de nuestro Firebase console , podemos ver que la operación de lectura fue denegada:

Attempt to read /records with auth=Success(null)
    /
    /records

No .read rule allowed the operation.
Read was denied.

La operación fue denegada porque ninguna regla de lectura permitía el acceso a la ruta /records/ , pero tenga en cuenta que la regla para rec1 nunca se evaluó porque no estaba en la ruta que solicitamos. Para recuperar rec1 , necesitaríamos acceder a él directamente:

var db = firebase.database();
db.ref("records/rec1").once("value", function(snap) {
  // SUCCESS!
}, function(err) {
  // error callback is not called
});

FIRDatabaseReference *ref = [[FIRDatabase database] reference];
[[ref child:@"records/rec1"] observeSingleEventOfType:FEventTypeValue withBlock:^(FIRDataSnapshot *snapshot) {
    // SUCCESS!
}];

var ref = FIRDatabase.database().reference()
ref.child("records/rec1").observeSingleEventOfType(.Value, withBlock: { snapshot in
    // SUCCESS!
})

FirebaseDatabase database = FirebaseDatabase.getInstance();
DatabaseReference ref = database.getReference("records/rec1");
ref.addListenerForSingleValueEvent(new ValueEventListener() {
  @Override
  public void onDataChange(DataSnapshot snapshot) {
    // SUCCESS!
  }

  @Override
  public void onCancelled(FirebaseError firebaseError) {
    // error callback is not called
  }
});

curl https://docs-examples.firebaseio.com/rest/records/rec1
# SUCCESS!

variable de ubicación

Las reglas de bases de datos en tiempo real admiten una variable $location para hacer coincidir los segmentos de ruta. Utilice el prefijo $ delante de su segmento de ruta para hacer coincidir su regla con cualquier nodo secundario a lo largo de la ruta.

  {
    "rules": {
      "rooms": {
        // This rule applies to any child of /rooms/, the key for each room id
        // is stored inside $room_id variable for reference
        "$room_id": {
          "topic": {
            // The room's topic can be changed if the room id has "public" in it
            ".write": "$room_id.contains('public')"
          }
        }
      }
    }
  }

También puede utilizar la $variable en paralelo con nombres de ruta constantes.

  {
    "rules": {
      "widget": {
        // a widget can have a title or color attribute
        "title": { ".validate": true },
        "color": { ".validate": true },

        // but no other child paths are allowed
        // in this case, $other means any key excluding "title" and "color"
        "$other": { ".validate": false }
      }
    }
  }