Исправление небезопасных правил

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

Если вы получили предупреждение о том, что ваша база данных Cloud Firestore не защищена должным образом, вы можете устранить уязвимости, изменив и протестировав свои правила безопасности Cloud Firestore.

Чтобы просмотреть существующие правила безопасности, перейдите на вкладку «Правила» в консоли Firebase.

Ознакомьтесь с правилами безопасности Cloud Firestore.

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

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

Распространенные сценарии с небезопасными правилами

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

Открытый доступ

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

Не рекомендуется: доступ для чтения и записи для всех пользователей.
// Allow read/write access to all users under any conditions
// Warning: **NEVER** use this rule set in production; it allows
// anyone to overwrite your entire database.

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}
Решение: правила, ограничивающие доступ на чтение и запись.

Создавайте правила, которые имеют смысл для вашей иерархии данных. Одним из распространенных решений этой проблемы безопасности является безопасность на основе пользователей с помощью аутентификации Firebase. Узнайте больше об аутентификации пользователей с помощью правил .

Только владелец контента

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

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

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 != null && request.auth.uid == request.resource.data.author_uid
    }
  }
}
  

Доступ для любого аутентифицированного пользователя

Иногда правила безопасности Cloud Firestore проверяют, вошел ли пользователь в систему, но не ограничивают доступ на основе этой аутентификации. Если одно из ваших правил включает auth != null , подтвердите, что вы хотите, чтобы любой вошедший в систему пользователь имел доступ к данным.

Не рекомендуется: любой вошедший в систему пользователь имеет доступ для чтения и записи ко всей вашей базе данных.
service cloud.firestore {
  match /databases/{database}/documents {
    match /some_collection/{document} {
      allow read, write: if request.auth != null;
    }
  }
}
Решение: Ограничить доступ с использованием условий безопасности.

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

Ролевой доступ

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 request.auth != null && get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == "Reader"
     allow write: if request.auth != null && 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.
    }
  }
}

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

// 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 "admin" attribute set
// to "true" grants write access to data

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

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

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

Закрытый доступ

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

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

SDK администратора Firebase и облачные функции по-прежнему смогут получить доступ к вашей базе данных. Используйте эти правила, если вы собираетесь использовать Cloud Firestore в качестве серверной части в сочетании с Firebase Admin SDK. Несмотря на то, что это безопасно, вам следует проверить, могут ли клиенты вашего приложения правильно получать данные.

Узнайте больше о правилах безопасности Cloud Firestore и о том, как они работают, в разделе «Начало работы с правилами безопасности Cloud Firestore ».

Проверьте правила безопасности Cloud Firestore

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

Чтобы быстро протестировать обновленные правила безопасности Cloud Firestore в консоли Firebase, используйте инструмент Rules Playground.

  1. Чтобы открыть «Площадку правил», нажмите «Площадка правил» на вкладке «Правила» .
  2. В настройках игровой площадки «Правила» выберите параметры теста, в том числе:
    • Тестирование чтения или записи
    • Определенное местоположение в вашей базе данных в виде пути.
    • Тип аутентификации — неаутентифицированный, аутентифицированный анонимный пользователь или конкретный идентификатор пользователя.
    • Данные, специфичные для документа, на которые конкретно ссылаются ваши правила (например, если ваши правила требуют наличия определенного поля, прежде чем разрешить запись).
  3. Нажмите «Выполнить» и найдите результаты на баннере над окном правил.