秘密情報の扱い — 鍵やパスワードを隠す

秘密（APIキー・DBパスワード・署名鍵）が漏れると、DBの中身を抜かれたり、外部サービスを勝手に使われて課金されたり——被害が直接的です。中級で押さえたいのは、秘密は「置き場所」だけでなく「経路」でも漏れるという視点です。

• コードに直書き — リポジトリの履歴に残り、公開・共有で流出
• フロントへの埋め込み — ブラウザに配るコードは全部読まれる前提
• ログ・エラー出力 — トークンをそのまま出すと保存先から漏れる
• CI/CDの設定 — ビルドログや設定ファイルに平文で残る

1. コードの外に置く — 環境変数や専用のシークレットマネージャ（Vault、クラウドのKMS／Secrets Manager）に保管し、実行時に読み込む
2. リポジトリに入れない — .gitignore で秘密ファイルを除外し、シークレットスキャンで混入を自動検知する
3. フロントに置かない — 秘密が要る処理はサーバ側に寄せ、ブラウザには渡さない
4. 最小権限 — 1つの鍵は必要な範囲だけに使わせ、用途ごとに分ける
5. ローテーション — 定期的に、また漏れたら即、鍵を新しくする

置き場所は用途と規模で選びます。

• 環境変数 — 小規模や単一サービスで手軽。ただしプロセスやログから見えやすい点に注意
• シークレットマネージャ（Vault・クラウドのSecrets Manager） — 一元管理・アクセス制御・監査・自動ローテーションを仕組み化できる
• KMS（鍵管理サービス） — 暗号鍵そのものを預け、鍵を取り出さずに暗号化や署名を実行させる

規模が大きくなるほど、誰が・いつ・どの鍵を使ったかを追える管理へ寄せるのが定石です。

• リポジトリへの混入 — 一度でも公開されたら「漏れた」扱い。履歴を消すより先に無効化＆差し替え
• ビルドでフロントに露出 — 埋め込んだ鍵はブラウザから読める。サーバ側に寄せる
• ログに秘密を出す — エラーログやアクセスログにトークンを出さない
• 共有しすぎ・放置 — 1つの鍵を広く使い回すと被害が拡大。ローテーションされない鍵も危険