有効期限のないAPIキーの問題点
何年も前に発行され、一度もローテーションされず、今も有効なキーは、便利なものではありません。何年も誰も実際に確認していない負債です。
私たちがブラウザー向けSDKを最初に作らなかった理由
ブラウザ向けSDKは要望しやすいものですが、ジオコーディングやIP検索のAPIが実際に行う処理の多くにとっては、本当によくない考えです。IPアドレスから位置を割り出すことに意味があるのは、まさにそれがサーバー上で行われ、リクエストの実際の送信元が見えるからです。同じ検索を訪問者のブラウザで動くクライアント側のJavaScriptに組み込んでも、連携が便利になるわけではありません。認証済みのAPIキーを、リクエスト経路全体の中で誰でも開発者ツールを開いて読み取れる唯一の場所に移しただけです。
そのため、当社はプレーンなHTTPサポートと互換ホストよりもブラウザ向けSDKを優先しませんでした。X-API-Keyヘッダー、Bearerトークン、HTTP Basic認証、クエリパラメーターのいずれで渡されたキーも、すべてのホストで同じように機能し、サーバー側のコードがすでにある場所から呼び出せます。バックエンドサービス、サーバーレス関数、バッチジョブなど、リクエストが、管理できないブラウザのタブではなく、お客様が管理するインフラから送信される理由がすでにある場所であればどこでも使えます。
特にIPジオロケーションは、サーバー側でしか意味を持ちません。この検索の価値はすべて、リクエストを送っている実際のIPアドレスを割り出すことから生まれます。不正チェック、ローカライズ、販売するのではなく自社で管理する分析など、意味のあるほとんどの用途では、そのIPアドレスが信頼できる場所、つまりリクエストを直接受け取るお客様のサーバーで検索を行う必要があります。クライアント側の呼び出しが報告する「IP」が無関係であるか、簡単に偽装できてしまうブラウザ環境で行うべきではありません。
入力された住所のジオコーディングは、サーバー専用かどうかがそれほど明確ではありません。住所オートコンプリートを、まず自社のバックエンドを経由するラウンドトリップなしに、ブラウザ上のフォームで直接すばやく反応させたいという要望には、それなりの理由があります。当社は、そうしたパターンがいずれ存在すること自体には反対していません。反対しているのは、それを最初の主要な連携方法として構築し、実際の用途の大半(チェックアウトフロー、送料計算、不正チェック)が本当に必要とし、認証情報を公開する必要のないプレーンなサーバー側HTTPアクセスよりも優先することです。
当社が異議を唱えているのは、特定の種類のデータへのクライアント側アクセスが理にかなっているかどうかに関係なく、「ブラウザ向けSDKを提供している」ことを、すべてのAPIが備えているべきチェック項目として扱う広い風潮です。サーバー側の文脈こそが要点である検索にとって、ブラウザ向けSDKは主に「モダンで便利に見えるか」というマーケティング上の問いに答えるだけで、その代わりに「この認証情報は最終的にどこに置かれるのか」という現実のセキュリティ上の問いを犠牲にします。当社は、まずセキュリティの問いに答え、利便性はその後についてくるようにしたいと考えています。その逆ではありません。
だからといって、アカウントの実際の認証情報がなくても機能するフォームのオートコンプリートのように、クライアント側での利用が本当に理にかなっている場面に特化した、より軽量でブラウザに適したツールをいずれ提供する可能性がなくなるわけではありません。ただし、それは、実際の連携の大半をすでに安全にカバーしているプレーンなHTTPの方法よりも先に、お客様に信頼をお願いする最初のものであるべきではありません。