Как взламывают приложения через неправильные настройки Firebase
Разработчики мобильных приложений часто совершают критическую ошибку, считая конфигурацию Firebase, вшитую в приложение, гарантией безопасности. Но спрятать ключи от сейфа — не значит защитить его содержимое.
Настоящая проблема начинается там, где аутентификация («кто вы?») выдаёт себя за авторизацию («что вам можно?»). Firebase Security Rules — это не декорация, а последний рубеж обороны ваших данных.
Конфигурация Firebase в вашем приложении — это не пароль от банковского хранилища. Это скорее адрес и инструкция по входу в здание. Если дверь заперта на висячий замок, достаточно знать, где она находится.
Разберём распространённую ловушку, в которую попадаются тысячи мобильных разработчиков.
Аутентификация — это ещё не всё
Многие разработчики, настраивая Security Rules для базы данных Firestore, ограничиваются проверкой: «А залогинен ли пользователь?». Правило выглядит примерно так: «Разрешить чтение, если request.auth != null». Звучит логично: без логина — нет доступа.
Но это катастрофически недостаточно. Проверка request.auth отвечает только на вопрос: «Это вообще зарегистрированный человек?». Она молчит о самом главном:
- Принадлежит ли запрашиваемая запись именно этому пользователю? (Может, он пытается читать чужой профиль).
- Имеет ли он право менять эти конкретные поля? (Может, он меняет себе статус на «Администратор»).
- Верно ли бизнес-состояние для этой операции? (Может, он пытается повторно использовать уже потраченный промокод).
Такая проверка — как паспортный контроль, который смотрит только на наличие документа, не сверяя лицо с фото. Атакующий может просто подставить валидный токен другого пользователя (или использовать свой) и выполнить запрос к чужим данным, если правила это позволяют.
Проверка приложения — не панацея
Google предлагает инструмент App Check, который пытается убедиться, что запрос идёт из настоящего приложения, а не из скрипта или модифицированной версии. Это полезный слой защиты, но он не решает ключевую проблему.
App Check — это как проверка, что письмо пришло из вашего дома, а не от соседа. Но он не проверит, кто именно из домашних его написал и что там написано. Он не валидирует права доступа к ресурсам и не доверяет данным, которые присылает клиент.
Надёжная модель безопасности — это многослойный пирог:
- Аутентификация определяет личность.
- Security Rules авторизуют доступ к данным.
- App Check повышает уверенность в контексте приложения.
- Доверенный бэкенд обеспечивает целостность бизнес-логики.
Сломается один слой — остальные должны остановить атаку.
Операции, которые нельзя доверять клиенту
Есть целый класс действий, которые категорически нельзя реализовывать только на стороне мобильного приложения, даже с самыми хитрыми клиентскими проверками. Это критические бизнес-операции: финансовые транзакции, вывод средств, одобрение KYC-верификации, назначение ролей администратора, начисление бонусов.
Их место — на вашем сервере, в доверенном бэкенде. Приложение должно отправлять запрос, а сервер:
- Проверять личность и права инициатора.
- Сверять текущее состояние системы.
- Валидировать входные данные.
- Гарантировать идемпотентность (защиту от повторного выполнения).
- Корректно обрабатывать конкурентные запросы и частичные сбои.
Клиент может отправить что угодно. Сервер должен доверять только себе.
Security Rules — это ваш код
Финальная и самая частая ошибка — отношение к правилам безопасности Firestore и Storage как к чему-то второстепенному, что «допилим потом». Это такой же код, как и ваш бэкенд. Он требует:
- Контроля версий и ревью перед деплоем.
- Тестирования на реальных сценариях (включая попытки межпользовательского и неавторизованного доступа).
- Проверки на уровне полей (а не только коллекций).
- Принципа наименьших привилегий для сервисных аккаунтов.
- Лимитов на операции и частоту запросов.
- Мониторинга и алертов на аномальную активность.
Бюджетные алерты от Firebase вас предупредят, что кто-то сливает ваш бюджет на чтение данных, но не остановят само слияние. Остановить может только правильно написанное правило.
Вывод: перестаньте верить клиенту
Безопасность мобильного приложения с Firebase не начинается и не заканчивается на том, чтобы спрятать конфигурационные ключи из репозитория. Это необходимое, но совершенно недостаточное действие.
Безопасная архитектура предполагает, что злоумышленник может:
- Декомпилировать ваше приложение и увидеть все ключи.
- Перехватить и модифицировать любой запрос из приложения.
- Подставить чужой токен авторизации.
- Написать собственный скрипт, который будет делать запросы напрямую.
Ваша задача — выстроить систему так, чтобы даже при выполнении всех этих пунктов атакующий не смог навредить системе или получить несанкционированный доступ к данным. Это достигается только строгой серверной авторизацией, проверкой бизнес-правил на бэкенде и грамотно прописанными Security Rules, которые работают не как широкая решетка, а как точечный фильтр.
Не прячьте ключи — стройте крепость.