よくある誤解

.envにクレデンシャルを記載すれば安全
.envはコミットすべきではない

これらの認識には注意が必要だ。それぞれの誤解を正し、適切な対応方法を以下に説明する。

クレデンシャルを.envに記載すべきではない理由

.envファイルにクレデンシャルを隔離してソースコードと分離しても、安全とは言えない。理由は以下の通りだ。

公開アプリへの含有リスク
.envに記述されたクレデンシャルは、ソースツリーにコミットしなくても、アプリをビルドしてリリースする際にアプリのパッケージに含まれる。その結果、リバースエンジニアリングされて漏洩するリスクが高い。
サーバーサイドとモバイルアプリの違い
.envを利用した分離は、主にサーバーサイドでの安全性を高めるための手法だ。サーバーでは、誤ってクレデンシャルを共有しないために有効だが、Flutterのようなクライアントサイドアプリでは、パッケージの解析による情報漏洩を防ぐことはできない。

クレデンシャルの適切な保存方法

クレデンシャルはアプリ内に直接保存するのではなく、サーバー側から付与するのがベストだ。以下の仕組みを活用すれば、アプリの正当性を検証した上で必要なクレデンシャルを安全に渡すことができる。

iOSの場合
App Attestを利用して、サーバー側でアプリの正当性を検証する。
Androidの場合
Play Integrity APIや、古いバージョンではSafetyNet Attestation APIを用いて、アプリが正規のものであるかを確認する。

サーバー側でアプリの検証が完了した後に、必要なクレデンシャルを提供する仕組みを構築するのが安全だ。
（とはいえ、それも工数がかかる対応なので、リスクが低いものに対してまで必要かどうかは疑問でもある。クレデンシャルが漏洩した際にそれがどれだけのリスクになるか次第で、どこまで厳重にするか判断すれば良い。）

.envファイルをコミットするべきケースと避けるべきケース

.envファイルのコミットについては、用途次第で判断する必要がある。

コミットすべき場合
本番やテスト環境の設定値を含む.envファイルは、誤った設定でビルドするリスクを防ぐため、コミットして管理すべきだ。これにより、一貫性のある環境構築が可能になる。
コミットすべきでない場合
開発者ごとのローカル設定を記載した.envファイルは、開発者ごとに変更が発生し、チームでの管理が煩雑になるため、コミットを避けるべきだ。

結論

.envの利用意義は、クライアントアプリとサーバサイドでは異なることを理解し、思い込みで誤用して事故になったり不要に非効率な運用をしないようにしたいものだ。
クレデンシャルに関しては、できればサーバサイドから渡すようにし、.envをコミットするかどうかは必要性を考えて判断すれば良い。