rest — Является ли Firebase Admin SDK для PHP эффективным способом скрытия учетных данных Firebase?
До сих пор я узнал, что Firebase Правила безопасности играют важную роль в обеспечении безопасности наших данных независимо от используемой нами платформы. Но я обнаружил, что комбинация Web + JavaScript и другие реализации могут быть подвержены риску, если разработчики структурируют их так, чтобы учетные данные firebase можно было легко увидеть в клиентских сценариях.
К счастью, Firebase имеет поддержку API REST на разных языках, которые могут как-то снизить риск. Для этого я взглянул на Krayit’s Firebase Admin SDK для PHP для портала администрирования веб-данных, который я создаю.
Вот простой демонстрация для Firebase Admin SDK для PHP.
Следующие хорошие моменты, которые я нашел для этой библиотеки:
- Учетные данные Firebase написаны на серверных сценариях, они скрыты на клиентских компьютерах
- Запросы и операции с базами данных и их реализация скрыты от клиентов.
- Имеет внутреннюю поддержку базы данных в реальном времени Firebase, аутентификацию и управление пользователями
Мои вопросы:
- Действительно ли мои учетные данные Firebase действительно безопасны, не будут ли они переданы миру при использовании этого подхода, а не просто помещены в простой файл javascript?
- Существуют ли другие способы сделать учетные данные и данные firebase более безопасными (кроме шифрования данных, сокрытия их в серверных сценариях посредством реализации REST и правильно структурированных правил безопасности)?
Заранее благодарю за ваши комментарии и предложения.
Решение
Нет риска для безопасности при раскрытии информации, такой как ключ API или идентификатор проекта, в вашем приложении (см. https://firebase.google.com/docs/web/setup, это рекомендуемая процедура) — ваше веб-приложение может делать только то, что разрешено делать аутентифицированному пользователю.
Конечно, существует риск того, что правила безопасности не определены должным образом, но это также относится и к бэкэнд-приложению — глупый пример: когда вы создаете учетную запись без пароля на сервере, любой может войти в систему с этой учетной записью ^^.
Что касается Admin SDK: их основная цель — выполнять административные и / или внутренние задачи. Если вы перенесете свою бизнес-логику с клиента (= браузера) на серверную часть, вы потеряете многие функции, которые веб-библиотеки предоставляют «из коробки». Вам придется заново реализовать функциональность, передавать данные из внешнего интерфейса в бэкэнд и обратно … Я не думаю, что это стоило бы хлопот.
Итак, я рекомендую: не беспокойтесь о фрагменте конфигурации, который виден при просмотре кода JS в браузере, и тщательно проверяйте свои правила безопасности, желательно с помощью автоматизированного набора тестов, и у вас все будет хорошо.
Другие решения
Других решений пока нет …