APIキーをHTTPヘッダーに含める理由

APIキーを扱う案件が出てきた。
postmanを利用して返ってくる値が、取得したい値になっているか確認し対応をしていた。

その時ふと思ったのが、ヘッダーにAPIキーを入れていること。
そういうものなんだろうと思えばそれで終わりだが、少しだけ調べてみることにした。
だってヘッダーってHTMLでしか聞いたことがなかったから。

---

APIキーをHTTPヘッダーに含める理由

機密情報をURLに含めない

APIキーをヘッダーで送ることで下記のリスクを回避できる。

• URL履歴に残ることを防げる
  • URLに直接APIキーを入れるとブラウザのURL履歴に残ってしまう
    • 他の人がパソコンを見た時にURLを見れば盗まれる可能性がある
• ログファイルに記録されにくい
  • ログファイルは誰が・いつ・どんなリクエストを送ったか見れるファイル
    • URLに直接APIキーを貼るとこのファイルを見れる人間に盗まれる可能性がある
• 他人とURLを共有してもキーが見えない

---

認証情報の管理がしやすい

APIキーをヘッダーに入れると、HTTPメソッド（GET、POSTなど）に関係なく、同じ方法で認証情報を扱えるため、実装がシンプルになる。

---

他技術との整合性がある

GoogleのgRPCベースAPI（Googleが開発したAPI）はHTTPヘッダー経由でのみAPIキーを渡すことができる。

APIキー送信方法と比較

HTTPヘッダー

メリット

• URLに含まれないため漏洩リスクが低い
• HTTPS通信時は暗号化される

デメリット

• ブラウザなど一部のクライアントでは利用できないケースもある

---

クエリパラメータ（例: ?key=...）

url
https://example.com/api/data?key=YOUR_API_KEY

メリット

• 実装が簡単

デメリット

• URL履歴・ログ・外部参照などで漏洩リスクが高い
  ※Googleでも非推奨

---

リクエストボディ（例: JSON形式）

{
  "key": "YOUR_API_KEY",
  "data": "example"
}

メリット

• URLに含まれず見えにくい

デメリット

• GETメソッドでは使用できない
• 認証とデータが混在。設計が不自然になる

---

フロントエンド公開時のセキュリティ対策

下記の対策を組み合わせることでAPIキーの不正使用を防ぐ。

• ドメイン制限（リファラ制限）
  • リクエストのリファラヘッダーをチェックして許可されたドメイン以外からのアクセスブロック

例：
ブラウザはAPIサーバーにリクエストを送るとき、Referer: https://your-site.com を自動で付ける
Googleはそれを見て「このサイトから来たリクエストならOK」と判断

• IPアドレス制限
  • このIPアドレスからしかリクエストを受け付けないとする方法
    • 主にサーバー側でAPIキーを使う場合に有効
• 利用可能APIの制限
  • このキーではgooglemapしか利用できない等の制限
    • 漏えいしても被害が小さくなる
• リクエスト数制限（レートリミット）
  • 一定時間内に許可するリクエスト数を制限する
    • Botやスクリプトの大量リクエストの悪用を防げる