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

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

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

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

Ознакомьтесь Cloud Firestore Security Rules

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

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

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

Cloud Firestore Security Rules вы, возможно, установили по умолчанию или при первоначальной разработке приложения с помощью 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;
    }
  }
}

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;

    }
  }
}
  

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

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

Иногда Cloud Firestore Security Rules проверяют, вошел ли пользователь в систему, но не ограничивают доступ на основе этой аутентификации. Если одно из ваших правил включает 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 Security Rules и о том, как они работают, в разделе «Начало работы с Cloud Firestore Security Rules .

Проверьте Cloud Firestore Security Rules

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

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

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