#reactjs #firebase #environment-variables
#reactjs #firebase #переменные среды
Вопрос:
Я создаю приложение react с интеграцией firebase, и переменные среды, которые мы используем, можно проверить, взяв источник страницы страницы на развернутом веб-сайте.
Мне интересно узнать некоторые способы сделать его более безопасным. единственный способ, который я могу придумать, — это принимать значения из API, чтобы они ни в коем случае не отображались в коде.
Для подключения к firebase я могу использовать метод зарезервированного URL для автоматического подключения.Firebase remote config позволяет хранить пары ключ-значение. Я думал о том, чтобы переместить все мои переменные env, чтобы удалить config setup и использовать его оттуда. Таким образом, я могу полностью удалить свой файл .env и избежать раскрытия каких-либо жестко заданных значений.
Кто-нибудь уже пробовал это? что может быть рекомендуемым способом сделать.значения env безопаснее?
Комментарии:
1. Обычно я позволяю серверной части обрабатывать все конфиденциальные вызовы API. Например, если я хочу подключиться к некоторым защищенным службам с помощью ключа API, я бы позволил своему бэкэнду выполнить вызов, а затем вернуть ответ интерфейсу. Поскольку у вас нет серверной части, вы можете установить ограничение API для своих ключей API . это означает, что они не смогут многого сделать, даже если получат ваш ключ API firebase путем отладки
Ответ №1:
Вы никогда не должны загружать в браузер какие-либо значения, к которым вы не хотите, чтобы пользователи могли получить доступ, точка. Браузер — это открытая книга, и, хотя вы можете скрыть значения, изменив, где и как они загружаются, вы не можете помешать мотивированному злоумышленнику прочитать абсолютно все, что вы делаете на клиенте.
Вот почему Firebase спроектирована так, чтобы иметь ключи API и конфигурацию, которые безопасны для публичного чтения — когда вы пишете правила безопасности, вы, по сути, устанавливаете границы вокруг того, что могут делать клиенты.
Firebase Remote Config можно и нужно использовать для значений, которые безопасны для клиентов — таких вещей, как флаги функций или URL-адреса для API, зависящие от среды. Его не следует использовать для конфиденциальных вещей, таких как закрытые ключи API и секреты.
Комментарии:
1. спасибо за предложение. Что мы будем делать с секретными ключами в вашем приложении. где мы сохраним его, чтобы быть в безопасности? создание коллекции в firebase и ее хранение там означало бы, что каждому входящему пользователю необходим доступ к ней. как насчет базы данных в реальном времени?
2. Для этого это будет зависеть от многих вещей — каковы секретные ключи? К чему они предоставляют доступ? Кому и когда нужно их использовать? Вы должны разработать свою модель безопасности таким образом, чтобы любой, кто не должен видеть значение, никогда не имел этого значения в своем клиенте. Это может быть достигнуто большим количеством различных способов.
3. Это значения конфигурации для подключения к вторичной базе данных firestore. Они доступны пользователям, имеющим достаточные разрешения. Доступ контролируется правилами. Но конфигурация для подключения теперь остается в моем файле .env.