Est-il sûr d'exposer Firebase apiKey au public ?

Question

El Guide Firebase Web-App indique que je devrais mettre le apiKey dans mon 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>

Ce faisant, le apiKey est exposé à chaque visiteur.

Quel est le le but de cette clé et est-ce que c'est vraiment destiné à être public ?

Answer 1

Je pense qu'une fois les règles de la base de données rédigées avec précision, cela suffira à protéger vos données. En outre, il existe des directives que l'on peut suivre pour structurer sa base de données en conséquence. Par exemple, créer un nœud UID sous les utilisateurs, et y placer toutes les informations qui s'y rapportent. Ensuite, vous devrez mettre en œuvre une règle de base de données simple comme ci-dessous

  "rules": {
    "users": {
      "$uid": {
        ".read": "auth != null && auth.uid == $uid",
        ".write": "auth != null && auth.uid == $uid"
      }
    }
  }
}

Aucun autre utilisateur ne pourra lire les données des autres utilisateurs, et la politique de domaine limitera les demandes provenant d'autres domaines. On peut en savoir plus sur ce sujet sur Règles de sécurité de Firebase

Answer 2

Après avoir lu cet article et effectué quelques recherches sur les possibilités, j'ai trouvé une approche légèrement différente pour limiter l'utilisation des données par les utilisateurs non autorisés :

J'enregistre mes utilisateurs dans ma base de données également (et j'y enregistre les données de profil). J'ai donc défini les règles de la base de données comme suit :

".read": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()",
".write": "auth != null && root.child('/userdata/'+auth.uid+'/userRole').exists()"

De cette façon, seul un utilisateur précédemment enregistré peut ajouter de nouveaux utilisateurs dans la base de données, de sorte qu'il n'y a aucun moyen pour quiconque sans compte d'effectuer des opérations sur la base de données. De plus, l'ajout de nouveaux utilisateurs n'est possible que si l'utilisateur a un rôle spécial et que l'édition n'est possible que par l'administrateur ou par cet utilisateur lui-même (quelque chose comme ceci) :

"userdata": {
  "$userId": {
    ".write": "$userId === auth.uid || root.child('/userdata/'+auth.uid+'/userRole').val() === 'superadmin'",
   ...

Answer 3

Il est normal de les inclure, et une attention particulière est requise uniquement pour Firebase ML ou lors de l'utilisation de Firebase Authentication.

Les clés API pour Firebase sont différentes des clés API classiques : Contrairement à la façon dont les clés API sont généralement utilisées, les clés API pour les services Firebase ne sont pas utilisées pour contrôler l'accès aux ressources backend ; cela ne peut être fait qu'avec les règles de sécurité Firebase. Habituellement, vous devez garder fastidieusement les clés API (par exemple, en utilisant un service de coffre-fort ou en définissant les clés comme variables d'environnement) ; cependant, les clés API pour les services Firebase peuvent être incluses dans le code ou dans les fichiers de configuration vérifiés.

Bien que les clés d'API pour les services Firebase puissent être incluses en toute sécurité dans le code, il existe quelques cas spécifiques où vous devez appliquer des limites pour votre clé d'API ; par exemple, si vous utilisez Firebase ML ou Firebase Authentication avec la méthode de connexion par email/mot de passe. Vous en saurez plus sur ces cas plus tard sur cette page.

Pour plus d'informations, consultez les documents officiels

Answer 4

Je suis en train de créer un site de blog sur des pages github. J'ai eu l'idée d'intégrer des commentaires à la fin de chaque page de blog. Je comprends comment firebase obtient et donne les données.

J'ai testé de nombreuses fois avec le projet et même en utilisant la console. Je ne suis pas du tout d'accord pour dire que Vlit est vulnérable. Croyez-moi, il n'y a pas de problème pour montrer votre clé api publiquement si vous avez suivi les étapes de confidentialité recommandées par Firebase. Allez à https://console.developers.google.com/apis et perf d'un steup de sécurité.

Answer 5

Vous ne devez pas exposer ces informations en public, en particulier les clés d'api. Cela peut conduire à une fuite de la vie privée.

Avant de rendre le site web public, vous devez le masquer. Vous pouvez le faire de 2 façons ou plus

1. Codage/cachetage complexe
2. Il suffit de placer les codes SDK de firebase au bas de votre site web ou de votre application pour que firebase fasse automatiquement tout le travail. Vous n'avez pas besoin de mettre les clés API nulle part.