firebase-security-rules-auditor

Официальный навык Firebase предназначен для аудита Firebase Security Rules в Firestore и Cloud Storage. Его роль — не настройка Firebase CLI и не развёртывание правил, а последовательная проверка того, можно ли обойти ограничения, получить чужие данные, повысить привилегии или отправить в хранилище состояние, которое правило должно было запретить. Источник описывает workflow как red-team assessment: проверяющий не считает правило безопасным только потому, что оно выглядит сложным, а ищет последовательность операций, которая приводит к обходу. Поэтому карточка подходит для ревью существующего набора правил и подготовки проверяемого JSON-отчёта, но сама по себе не является доказательством безопасности приложения. Первый обязательный блок — проверка расхождения между create и update. Нужно сравнить, какие поля и значения разрешено записать при создании документа, а затем выяснить, можно ли последующим update превратить корректный документ в недопустимое состояние. Источник приводит в качестве примеров изменение роли, обход ограничения размера и нарушение ожидаемого типа данных. Отдельно проверяется источник полномочий: если чувствительные поля role, isAdmin или ownerId принимаются из пользовательских данных request.resource.data, это требует осторожной оценки, потому что данные запроса не становятся доверенным источником авторизации сами по себе. Такой анализ связывает отдельные условия правила с последовательностью реальных операций, а не ограничивается чтением одного выражения. Второй блок касается соответствия бизнес-логике и злоупотребления ресурсами. Правила должны позволять приложению выполнять заявленный сценарий: например, в приложении для совместной работы участники действительно должны иметь предусмотренный доступ, иначе сломанные ограничения могут подтолкнуть команду к небезопасным обходам. Для Firestore и Storage также проверяются ограничения длины строк и размера массивов. Их отсутствие источник относит к риску resource exhaustion или DoS. Дополнительно проверяются типы полей через проверки вроде is string, is int и is timestamp. Это помогает отделить контроль доступа от валидации входных данных и обнаружить случаи, когда структура документа принимает неожиданные значения. Отдельное внимание уделяется различию между ограничением полей и проверкой личности. Условия hasOnly() и diff() могут ограничивать список изменяемых полей, но сами по себе не доказывают, что изменять документ имеет право именно владелец. Поэтому при обновлении нужно искать независимую ownership-проверку, например сопоставление resource.data.uid с request.auth.uid. Если любой аутентифицированный пользователь может менять поля в документе другого пользователя без такого условия, это рассматривается как нарушение целостности данных. Именно это разделение — field-level security против identity-level security — не даёт принять аккуратный список разрешённых полей за полноценную авторизацию. Источник также задаёт оговорку для ограниченного сценария администрирования. Проверка одного захардкоженного email администратора не должна сама по себе снижать оценку, если одновременно проверяется email_verified и реализация не позволяет дополнительным администраторам назначить себя или оставить путь эскалации. Итоговая шкала содержит пять уровней: 1 — критический несанкционированный доступ, повышение привилегий или полный обход валидации; 2 — серьёзная ошибка бизнес-логики, самоназначение роли или обход контроля; 3 — умеренная проблема, например раскрытие PII или непоследовательная проверка критичных полей; 4 — небольшая проблема вроде повреждения собственных данных, отсутствия лимита размера или слабой проверки типов; 5 — защищённый набор с полной валидацией, строгим ownership и безопасным ACL на ролях. Ответ должен быть JSON с полями score, summary и findings, где каждое finding содержит check, severity, issue и recommendation. Навык не предназначен для Firebase CLI login/deploy, Auth, Crashlytics, Remote Config или запросов к базе данных: его граница — анализ Security Rules и конкретных путей обхода.