Основные правила безопасности

Правила безопасности Firebase позволяют вам контролировать доступ к вашим сохраненным данным. Гибкий синтаксис правил означает, что вы можете создавать правила, которые соответствуют чему угодно, от всех операций записи во всю базу данных до операций над конкретным документом.

В этом руководстве описаны некоторые из наиболее простых вариантов использования, которые вы, возможно, захотите реализовать при настройке приложения и защите своих данных. Однако, прежде чем вы начнете писать правила, вы можете узнать больше о языке , на котором они написаны, и об их поведении .

Чтобы получить доступ к своим правилам и обновить их, выполните действия, описанные в разделе «Управление и развертывание правил безопасности Firebase» .

Правила по умолчанию: заблокированный режим

Когда вы создаете базу данных или экземпляр хранилища в консоли Firebase, вы выбираете, будут ли ваши правила безопасности Firebase ограничивать доступ к вашим данным ( заблокированный режим ) или разрешать доступ всем ( тестовый режим ). В Cloud Firestore и базе данных реального времени правила по умолчанию для заблокированного режима запрещают доступ всем пользователям. В облачном хранилище доступ к корзинам хранилища могут получить только пользователи, прошедшие проверку подлинности.

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 request.auth != null;
    }
  }
}

Правила среды разработки

Пока вы работаете над своим приложением, вам может понадобиться относительно открытый или беспрепятственный доступ к вашим данным. Просто не забудьте обновить свои правила перед развертыванием приложения в рабочей среде. Также помните, что если вы развертываете свое приложение, оно общедоступно, даже если вы его не запускали .

Помните, что Firebase разрешает клиентам прямой доступ к вашим данным, а правила безопасности Firebase — единственная защита, блокирующая доступ для злоумышленников. Определение правил отдельно от логики продукта имеет ряд преимуществ: клиенты не несут ответственности за обеспечение безопасности, реализации с ошибками не поставят под угрозу ваши данные, и, что наиболее важно, вы не полагаетесь на промежуточный сервер для защиты данных от всего мира.

Все аутентифицированные пользователи

Хотя мы не рекомендуем оставлять ваши данные доступными для любого пользователя, вошедшего в систему, может быть полезно установить доступ для любого пользователя, прошедшего проверку подлинности, во время разработки приложения.

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

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

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

Готовые к производству правила

Готовясь к развертыванию своего приложения, убедитесь, что ваши данные защищены и что доступ к ним предоставлен вашим пользователям должным образом. Используйте аутентификацию для настройки доступа на основе пользователей и чтения непосредственно из вашей базы данных для настройки доступа на основе данных.

Рассмотрите возможность написания правил при структурировании данных, поскольку способ настройки правил влияет на то, как вы ограничиваете доступ к данным по разным путям.

Доступ только для владельцев контента

Эти правила ограничивают доступ только для аутентифицированного владельца содержимого. Данные доступны для чтения и записи только одному пользователю, а путь к данным содержит идентификатор пользователя.

Когда это правило работает: это правило хорошо работает, если данные разрознены по пользователям — если единственный пользователь, которому нужен доступ к данным, — это тот же пользователь, который создал данные.

Когда это правило не работает: этот набор правил не работает, когда несколько пользователей должны записывать или читать одни и те же данные — пользователи перезапишут данные или не смогут получить доступ к созданным ими данным.

Чтобы настроить это правило: Создайте правило, которое подтверждает, что пользователь, запрашивающий доступ для чтения или записи данных, является пользователем, которому принадлежат эти данные.

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

{
  "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>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Смешанный публичный и частный доступ

Это правило разрешает всем читать набор данных, но ограничивает возможность создавать или изменять данные по заданному пути только для аутентифицированного владельца содержимого.

Когда это правило работает: это правило хорошо работает для приложений, которым требуются общедоступные элементы, но необходимо ограничить доступ к редактированию для владельцев этих элементов. Например, приложение для чата или блог.

Когда это правило не работает: Как и правило только для владельцев контента, этот набор правил не работает, когда несколько пользователей должны редактировать одни и те же данные. В конечном итоге пользователи перезапишут данные друг друга.

Чтобы настроить это правило: Создайте правило, которое разрешает доступ на чтение для всех пользователей (или всех пользователей, прошедших проверку подлинности) и подтверждает, что пользователь, записывающий данные, является владельцем.

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

{
// 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>/path/to/file.txt"
    match /user/{userId}/{allPaths=**} {
      allow read;
      allow write: if request.auth.uid == userId;
    }
  }
}

Доступ на основе атрибутов и ролей

Чтобы эти правила работали, вы должны определить и назначить атрибуты пользователям в ваших данных. Правила безопасности Firebase проверяют запрос на соответствие данным из вашей базы данных или метаданным файла для подтверждения или отказа в доступе.

Когда это правило работает: если вы назначаете роль пользователям, это правило позволяет легко ограничить доступ на основе ролей или определенных групп пользователей. Например, если вы храните оценки, вы можете назначить разные уровни доступа группе «Студенты» (только чтение их контента), группе «Учителя» (чтение и запись по их предмету) и группе «Директора» (чтение весь контент).

Когда это правило не работает: в базе данных реального времени и в облачном хранилище ваши правила не могут использовать метод get() , который могут включать правила Cloud Firestore. Следовательно, вы должны структурировать свою базу данных или метаданные файла, чтобы отразить атрибуты, которые вы используете в своих правилах.

Чтобы настроить это правило: В Cloud Firestore включите поле в документы ваших пользователей, которое вы можете прочитать, затем структурируйте свое правило, чтобы прочитать это поле и условно предоставить доступ. В базе данных реального времени создайте путь к данным, который определяет пользователей вашего приложения и предоставляет им роль в дочернем узле.

Вы также можете настроить пользовательские утверждения в Authentication , а затем получить эту информацию из переменной auth.token в любых правилах безопасности Firebase.

Атрибуты и роли, определяемые данными

Эти правила работают только в 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"
   }
  }
}

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

Атрибуты и роли пользовательских утверждений

Чтобы реализовать эти правила, настройте пользовательские утверждения в Firebase Authentication, а затем используйте утверждения в своих правилах.

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

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

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

Атрибуты аренды

Чтобы реализовать эти правила, настройте мультиарендность в Google Cloud Identity Platform (GCIP), а затем используйте арендатора в своих правилах. В следующих примерах разрешена запись от пользователя в конкретном арендаторе, например 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;
  }
}