web-dev-qa-db-fra.com

Est-il prudent d'exposer Firebase apiKey au public?

Le guide Web de l'application Firebase indique que je devrais mettre la clé apiKey donnée dans mon code HTML pour initialiser Firebase:

// 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>

En faisant cela, apiKey est exposé à chaque visiteur. Quel est le but de cette clé et est-ce vraiment censé être public?

javascriptfirebase
340
farmio

L'apiKey identifie essentiellement votre projet Firebase sur les serveurs de Google. Ce n'est pas un risque de sécurité pour quelqu'un de le savoir. En fait, il est nécessaire qu’ils le sachent pour pouvoir interagir avec votre projet Firebase.

En ce sens, il est très similaire à l'URL de la base de données utilisée historiquement par Firebase pour identifier le back-end: https://<app-id>.firebaseio.com. Voir cette question pour savoir pourquoi il ne s'agit pas d'un risque pour la sécurité: Comment restreindre la modification des données Firebase? , y compris l'utilisation des règles de sécurité côté serveur de Firebase pour garantir que seuls les utilisateurs autorisés peuvent accéder aux services dorsaux.

Si vous souhaitez savoir comment sécuriser l’ensemble des données, l’accès à vos services backend Firebase est autorisé, consultez la documentation sur règles de sécurité Firebase .

322
Frank van Puffelen

En me basant sur les réponses de prufrofro et de Frank van Puffelen ici , j’ai mis au point cette solution qui n’empêche pas le grattage, mais peut rendre plus difficile l’utilisation de votre clé API.

Attention: pour obtenir vos données, même avec cette méthode, on peut par exemple simplement ouvrir la console JS dans Chrome et taper:

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

Seules les règles de sécurité de la base de données peuvent protéger vos données.

Néanmoins, j'ai limité l'utilisation de ma clé d'API de production à mon nom de domaine, comme ceci:

  1. https://console.developers.google.com/apis
  2. Sélectionnez votre projet Firebase
  3. Informations d'identification
  4. Sous Clés d'API, choisissez votre clé de navigateur. Cela devrait ressembler à ceci: " Touche de navigateur (créée automatiquement par le service Google) "
  5. Dans " accepter les demandes de ces référents HTTP (sites Web) ", ajoutez l'URL de votre application (exemple: projectname.firebaseapp.com/*).

Maintenant, l'application ne fonctionnera que sur ce nom de domaine. J'ai donc créé une autre clé API qui sera privée pour le développement localhost.

  1. Cliquez sur Créer les informations d'identification> Clé API

Celui-ci n'est pas limité, alors assurez-vous de le garder privé.

Par défaut, comme mentionné par Emmanuel Campos, Firebase ne liste blanche que localhost et votre domaine d’hébergement Firebase .

Afin de m'assurer que je ne publie pas par erreur cette nouvelle clé d'API non restreinte, j'utilise l'une des méthodes suivantes pour utiliser automatiquement la clé restreinte en production.

Configuration de Create-React-App

Dans /env.development:

REACT_APP_API_KEY=###dev-key###

Dans /env.production:

REACT_APP_API_KEY=###public-key###

Dans /src/index.js

const firebaseConfig = {
  apiKey: process.env.REACT_APP_API_KEY,
  // ... 
};

Ma configuration précédente pour Webpack:

J'utilise Webpack pour créer mon application de production et j'insère ma clé API de développement dans mon index.html exactement comme vous le feriez normalement. Ensuite, dans mon fichier webpack.production.config.js, je remplace la clé chaque fois que index.html est copié dans la version de production:

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

Je ne suis pas convaincu d'exposer les clés de sécurité/configuration au client. Je ne dirais pas que c'est sécurisé, non pas parce que quelqu'un peut voler toutes les informations privées dès le premier jour, parce que quelqu'un peut faire une demande excessive, vider votre quota et vous faire devoir à Google beaucoup d'argent.

Vous devez penser à de nombreux concepts interdisant aux personnes de ne pas accéder à des sites où elles ne sont pas censées être, aux attaques DOS, etc.

Je préférerais que le client accède d’abord à votre serveur Web, là où vous mettez un pare-feu de première main, captcha, cloudflare, une sécurité personnalisée entre le client et le serveur, ou entre le serveur et la base de feu, et vous êtes prêt à partir. Au moins, vous pouvez d'abord arrêter l'activité suspecte avant qu'elle atteigne la base de feu. Vous aurez beaucoup plus de flexibilité.

Je ne vois qu'un bon scénario d'utilisation pour l'utilisation de la configuration basée sur le client pour les utilisations internes. Par exemple, vous avez un domaine interne et vous êtes presque certain que les étrangers ne peuvent pas y accéder. Vous pouvez donc configurer un environnement tel que browser -> firebase.

13
Teoman shipahi