Безопасно ли выставлять Firebase apiKey на всеобщее обозрение?


на firebase Web-App guide государства я должна поставить данное значение apiKey в моей HTML-код, чтобы инициализировать опорного пункта:

// TODO: Replace with your project's customized code snippet
<script src="https://www.gstatic.com/firebasejs/3.0.2/firebase.js"></script>
<script>
  // Initialize Firebase
  var config = {
    apiKey: '<your-api-key>',
    authDomain: '<your-auth-domain>',
    databaseURL: '<your-database-url>',
    storageBucket: '<your-storage-bucket>'
  };
  firebase.initializeApp(config);
</script>

таким образом, apiKey подвергается воздействию каждого посетителя. Какова цель этого ключа и действительно ли он должен быть общедоступным?

3 236

3 ответа:

apiKey по существу просто идентифицирует ваш проект Firebase на серверах Google. Это не угроза безопасности для кого-то, чтобы знать это. На самом деле, им необходимо это знать, чтобы они могли взаимодействовать с вашим проектом Firebase.

в этом смысле он очень похож на URL базы данных, который Firebase исторически использовался для идентификации серверной части:https://<app-id>.firebaseio.com. См. этот вопрос о том, почему это не является угрозой безопасности:как ограничить данные Firebase модификация?, включая использование правил безопасности на стороне сервера Firebase, чтобы гарантировать, что только авторизованные пользователи могут получить доступ к серверным службам.

опираясь на ответы prufrofro и Фрэнк Ван Puffelen здесь, я собрал это решение, которое не предотвращает выскабливание, но может затруднить использование вашего ключа API.

внимание: чтобы получить ваши данные, даже с помощью этого метода, можно, например, просто открыть консоль JS в Chrome и введите:

firebase.database().ref("/get/all/the/data").once("value", function (data) {
    console.log(data.val());
});

только правила безопасности базы данных могут защитить ваши данные.

тем не менее, я ограничил свой производственный API используйте ключ для моего доменного имени следующим образом:

  1. https://console.developers.google.com/apis
  2. выберите свой проект Firebase
  3. полномочия
  4. в разделе ключи API выберите ключ браузера. Это должно выглядеть так: "ключ браузера (автоматически созданный сервисом Google)"
  5. в "принимать запросы от этих Http-рефереры (веб-сайтах)", добавьте URL вашего приложения (например:projectname.firebaseapp.com/*)

теперь приложение будет работать только на этом доменном имени. Поэтому я создал еще один ключ API, который будет частным для разработки localhost.

  1. нажмите создать учетные данные > ключ API

это не ограничено, поэтому убедитесь, что вы держите его в секрете.

Я использую Webpack для создания своего рабочего приложения. Чтобы убедиться, что я не публикую этот новый неограниченный ключ API по ошибке, я помещаю его в свой index.html так же, как вы обычно делаете с вашим ключом API. Тогда, внутри моего webpack.production.config.js файл, я заменяю ключ каждый раз index.html копируется в производственную сборку, например:

plugins: [
    new CopyWebpackPlugin([
      {
        transform: function(content, path) {
          return content.toString().replace("###dev-key###", "###public-key###");
        },
        from: './index.html'
      }
    ])
  ]

по умолчанию, как упоминал Эммануэль Кампос,Firebase только белые списки localhost и ваш домен хостинга Firebase.

Я не убежден, чтобы предоставить ключи безопасности / конфигурации для клиента. Я бы не назвал это безопасным, не потому, что кто-то может украсть всю личную информацию с первого дня, потому что кто-то может сделать чрезмерный запрос, и слить свою квоту и заставить вас задолжать Google много денег.

вы должны думать о многих понятиях ограниченных людей, не открыть, где они не должны быть, DoS-атак и т. д.

Я бы больше предпочел, чтобы клиент сначала ударил по вашему веб-сервер, там вы ставите то, что когда-либо из первых рук брандмауэр , капча, cloudflare, пользовательская безопасность между клиентом и сервером, или между сервером и firebase, и вы хорошо идти. По крайней мере, вы можете сначала остановить подозрительную активность, прежде чем она достигнет firebase. У вас будет гораздо больше гибкости.

Я вижу только один хороший сценарий использования для использования конфигурации на основе клиента для внутреннего использования. Например, у вас есть внутренний домен, и вы уверены, что посторонние не могут получить туда доступ, поэтому вы можете настроить среду, как браузер - > тип firebase.