APIキーはGitHubにプッシュしていいのか？エンジニアの指摘から「ダブルブロック」の対策に行き着いた話

エンジニアの一言から始まった疑問

アプリ開発を進め、いざコードをGitHubにプッシュしようとしたときふと手が止まった。「あれ？そういえば、ソースコードに書かれているFirebaseのAPIキーって、そのままGitHubに上げても大丈夫なやつだっけ……？」

周りのエンジニアの友人に相談してみると、返ってきたのは即座の指摘だった。 「いやいや、APIキーなんだからGitHubにプッシュするのはアウトに決まっているでしょ！」

「やっぱりそうだよな……でも、Firebaseの入門記事とかを見ると、そのまま書いてあることもある気がするぞ……？」このモヤモヤを解消するため、公式ドキュメントや仕組みを改めて徹底的に調べてみることにした。

調べていくと、Googleの公式ドキュメント（Firebase）にはこう明記されていた。

「FirebaseサービスのAPIキーは秘密情報ではない」

そもそもWebアプリの仕組み上、ブラウザ（クライアントサイド）で動くJavaScriptの中にAPIキーが含まれる以上、ユーザーが「検証ツール」などを開けばキーはいつでも丸見えになってしまう。つまり、「隠すことができない仕様」になっているのだ。

だからこそ、Firebaseのクライアント用APIキーに関しては、「GitHubにコードをプッシュしたからといって、それ単体で即座にシステムが乗っ取られるわけではない」というのが公式の見解だった。

「見られても大丈夫」と言われると少し不安になるが、ここで重要になってくるのが「データの守り方」の考え方だ。

一般的なAPIキー（例えばAIのAPIやサーバー側の秘密鍵など）は、キーそのものを隠すことで不正利用を防ぐ。しかし、Firebaseの場合はキーの隠蔽ではなく、以下の2段構えで安全性を担保する設計になっている。

データベース側で「誰がどのデータにアクセスしていいか」のルールを厳しく設定する（例：ログイン済みのユーザーだけに絞るなど）。これさえしっかり書いておけば、仮にキーが見られてもデータを勝手に読み書きされることは防げる。

Google Cloud Console側で、そのキーを使ってアクセスできるサービスやドメインを厳しく制限しておく。

公式の仕様や仕組みを知ることで「なるほど、見られても致命傷にはならないんだな」と納得した。

しかし、最初にエンジニアの友人が言っていた「APIキーをコードに直書きしてプッシュするのはNG」という感覚も、実務やチーム開発の現場においては極めてまっとうで、安全第一なベストプラクティスだ。一般のシークレットキーを扱う感覚からすれば、直書きしたコードを公開するのはやはり心理的にも抵抗がある。

そこで今回は、どちらの意見も妥協せず「ダブルブロック」の体制をとることにした。

Firebaseのルールをテストモードから適切に設定し、不正なアクセスを根本からシャットアウトする。

コードへの直書きをやめ、.envファイルを使ってAPIキーを切り離し、GitHubにはプッシュされないようにする。

この対策により、仕様上の安全性だけでなく、チーム開発や実務を想定した「セキュリティ意識の高さ」も同時に満たすことができた。

今回の件で学んだのは、単に「仕様上セーフだから大丈夫」と油断するのではなく、なぜベテランエンジニアたちが「アウト」と言うのか（安全性を最大化したいという意識）背景を理解することの大切さだ。

公式の正しい知識（仕組み）をインプットしつつ、現場のベストプラクティス（環境変数など）を取り入れて多重に備える。この「ダブルブロック」の考え方は、これからのアプリ開発やポートフォリオ制作においても大きな自信になった。

同じように「これってGitHubに上げていいの？」と悩んでいるエンジニアの卵の方たちの参考になれば嬉しい。