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

Воспользуйтесь этим руководством, чтобы понять распространенные уязвимости в конфигурациях 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
    }
  }
}
  

Доступ к неподтвержденным адресам электронной почты

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

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

service cloud.firestore {
  match /databases/{database}/documents {
    // Allow access based on email domain
    match /some_collection/{document} {
     allow read: if request.auth != null
                 && request.auth.email_verified
                 && request.auth.email.endsWith('@example.com')
    }
  }
}

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

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

// 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 Functions по-прежнему могут получать доступ к вашей базе данных. Используйте эти правила, если вы планируете использовать Cloud Firestore в качестве серверной части в сочетании с SDK администратора Firebase. Хотя это безопасно, следует проверить, могут ли клиенты вашего приложения корректно получать данные.

Подробнее о 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. Нажмите кнопку «Выполнить» и найдите результаты в баннере над окном правил.