Firebase apiKeyを公開しても安全ですか？

FirebaseのWebアプリガイドは、私が与えられ置くべきと述べapiKeyFirebaseを初期化するために、私の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はすべての訪問者に公開されます。そのキーの目的は何ですか？それは本当に公開することを意図していますか？

この構成スニペットのapiKeyは、Googleサーバー上のFirebaseプロジェクトを識別するだけです。誰かがそれを知っていることは、セキュリティ上のリスクではありません。実際、Firebaseプロジェクトとやり取りするためには、それを知る必要があります。この同じ構成データは、Firebaseをバックエンドとして使用するすべてのiOSおよびAndroidアプリにも含まれています。

その意味で、同じスニペットでプロジェクトに関連付けられているバックエンドデータベースを識別するデータベースURLと非常に似ていますhttps://<app-id>.firebaseio.com。これがセキュリティリスクではない理由については、この質問を参照してください：Firebaseデータの変更を制限する方法？、Firebaseのサーバー側のセキュリティルールを使用して、承認されたユーザーのみがバックエンドサービスにアクセスできるようにします。

Firebaseバックエンドサービスへのすべてのデータアクセスを認証する方法を学びたい場合は、Firebaseセキュリティルールに関するドキュメントをご覧ください。

この構成データをバージョン管理にコミットするリスクを軽減したい場合は、Firebase HostingのSDK自動構成の使用を検討してください。キーは同じ形式でブラウザーに残りますが、それによってコードにハードコードされなくなります。

ここでプルフロフロとフランクファンプフェレンの回答を基に、スクレイピングを妨げないこの設定をまとめましたが、APIキーの使用が少し難しくなる可能性があります。

警告：この方法でもデータを取得するには、たとえば、ChromeでJSコンソールを開いて次のように入力します。

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リファラ（ウェブサイト）からの要求を受け入れる」、あなたのアプリ（exemple：のURLを追加しますprojectname.firebaseapp.com/*）

これで、アプリはこの特定のドメイン名でのみ機能します。そこで、localhost開発用にプライベートになる別のAPIキーを作成しました。

1. [認証情報を作成]> [APIキー]をクリックします

Emmanuel Camposが述べたように、デフォルトでは、FirebaseはホワイトリストlocalhostとFirebaseホスティングドメインのみをリストします。

間違ったAPIキーを誤って公開しないようにするために、次のいずれかの方法を使用して、制限の厳しいものを自動的に本番環境で使用します。

Create-React-Appのセットアップ

で/env.development：

REACT_APP_API_KEY=###dev-key###

で/env.production：

REACT_APP_API_KEY=###public-key###

に /src/index.js

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

以前のWebpackのセットアップ：

私はWebpackを使用して本番アプリをビルドし、通常どおりに開発APIキーを内部に配置index.htmlします。次に、webpack.production.config.jsファイル内で、index.html本番ビルドにコピーされるたびにキーを置き換えます。

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

セキュリティ/構成キーをクライアントに公開することに確信が持てません。誰かが最初の日からすべての個人情報を盗むことができるため、誰かが過度のリクエストを行い、割り当てを使い果たして、Googleに多額の金を借りさせることができるからではありません。

DOS攻撃など、人々が本来あるべき場所にアクセスできないように制限することから、多くの概念を考える必要があります。

私はクライアントが最初にあなたのウェブサーバーにぶつかることをもっと望みます、そこであなたは今までにないファイアウォール、キャプチャ、クラウドフレア、カスタムセキュリティをクライアントとサーバーの間、またはサーバーとファイアベースの間に置いて、あなたは行ってもいいです。少なくとも、疑わしいアクティビティをFirebaseに到達する前に停止することができます。はるかに柔軟性があります。

内部使用のためにクライアントベースの構成を使用するための1つの適切な使用シナリオのみが表示されます。たとえば、内部ドメインがあり、外部の人がそこにアクセスできないことを確信しているので、ブラウザのような環境をセットアップできます-> firebase type。

データベースのルールが正確に記述されれば、データを保護するのに十分だと私は信じています。さらに、それに応じてデータベースを構造化するために従うことができるガイドラインがあります。たとえば、ユーザーの下にUIDノードを作成し、その下にすべての情報を配置します。その後、以下のような単純なデータベースルールを実装する必要があります。

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

他のユーザーは他のユーザーのデータを読み取ることができません。さらに、ドメインポリシーは他のドメインからのリクエストを制限します。Firebaseセキュリティルールで詳細を読むことができ ます

ユーザー/パスワードのサインアップが有効になっている場合、APIキーの公開により脆弱性が生じます。APIキーを受け取り、誰でも新しいユーザーアカウントを作成できるようにするオープンAPIエンドポイントがあります。次に、この新しいアカウントを使用してFirebase Authで保護されたアプリにログインするか、SDKを使用してユーザー/パスで認証し、クエリを実行します。

これをGoogleに報告しましたが、意図したとおりに機能しているとのことです。

ユーザー/パスワードアカウントを無効にできない場合は、次の操作を行う必要があります。新しいユーザーを自動的に無効にするクラウド機能を作成し、そのユーザーのアクセスを管理する新しいDBエントリを作成します。

例：MyUsers / {userId} / Access：0

exports.addUser = functions.auth.user().onCreate(onAddUser);
exports.deleteUser = functions.auth.user().onDelete(onDeleteUser);

ルールを更新して、アクセスが1より大きいユーザーのみに読み取りを許可します。

オフのチャンスでは、リスナー関数がアカウントを十分に速く無効にしないため、読み取りルールによってデータを読み取ることができなくなります。

これを読んだ後、可能性についていくつかの調査を行った後、権限のないユーザーによるデータの使用を制限するために、少し異なるアプローチを考え出しました。

私も自分のDBにユーザーを保存します（そしてプロファイルデータをそこに保存します）。だから私はこのようにdbルールを設定するだけです：

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

この方法では、以前に保存されたユーザーのみが新しいユーザーをDBに追加できるため、アカウントを持たないユーザーがDBで操作を実行することはできません。また、新しいユーザーの追加は、ユーザーに特別な役割があり、管理者またはそのユーザー自身（次のようなもの）のみが編集できる場合にのみ可能です。

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

この情報は公開しないでください。公開では、特にapiキー。プライバシーの漏洩につながる可能性があります。

Webサイトを公開する前に、非表示にする必要があります。あなたは2つ以上の方法でそれを行うことができます

1. 複雑なコーディング/非表示
2. Firebase SDKコードをウェブサイトまたはアプリの下部に配置するだけで、Firebaseがすべて自動的に機能します。APIキーをどこにも置く必要はありません