多くのチームは、APIのセキュリティを認証の問題として扱います。トークンを発行し、すべてのルートでそれを検査し、これで仕事は終わったと考えます。そしてある日、テスターがURLの数字をひとつ書き換えるだけで、別の顧客の請求書を読み出します。

「認証済み」と「認可済み」のあいだにあるこの隙間こそ、実際のAPI侵害の大半が住み着いている場所です。しかもこれは、スキャナーが安定して見つけてくれる種類の問題ではありません。自動化されたツールは、有効なトークンと200の応答を見て成功と報告します。その応答に他人のデータが含まれていたと気づけるのは、あなたの業務ルールを理解している人間だけです。

核心となる区別: 認証は誰が呼び出しているのかを証明します。認可は、その呼び出し元が何を見てよく、何を変更してよいのかを決めるものであり、すべてのオブジェクトについて、すべてのリクエストで、データ層において強制されなければなりません。深刻なAPIの脆弱性のほとんどは、前者が完璧に動いている一方で、後者が失敗しているという形をとります。

オブジェクト単位の認可の欠落が支配的な理由

APIで最も多い深刻な欠陥は、説明としては最も単純なものでもあります。

エンドポイントは /api/invoices/48213 です。呼び出し元は認証済みなので、ハンドラーは請求書48213を取得して返します。その請求書が本当にその呼び出し元のものかを、誰も確認していません。数字を変えれば、他人の請求書が手に入ります。APIは書かれたとおりに動きました。書かれ方のほうが誤っていたのです。

この失敗は、あなたにとって都合の悪い方向に、そして攻撃者にとって都合のよい方向に規模を広げます。連番の識別子があれば、ループひとつでデータセット全体を列挙できます。推測しにくい識別子へ切り替えることは多少の助けにはなりますが、修正ではありません。識別子は別のエンドポイントや書き出しファイル、通知メールから漏れていくからです。

修正は偶発的なものではなく、構造的なものでなければなりません。所有関係はクエリそのものの中で確認する必要があります。つまり「この顧客に属する、この識別子の請求書を取得する」のであって、「請求書を取得したうえで、後続の何かが確認してくれることを願う」のではありません。そしてその強制はデータアクセス層に置いてください。半年後に、この段落を一度も読んだことのない誰かが新しいコントローラーを書くときにも、忘れようがなくなります。

同じ失敗は、オブジェクトだけでなく機能にも当てはまります。管理用のエンドポイントが、通常の利用者向けの管理画面からリンクされていないという事実だけで守られているなら、それはまったく守られていません。

実際に指摘されるAPIセキュリティの欠陥

認可以外では、いくつかの問題が指摘事項の大半を占めます。ここでの標準的な参照先はOWASP API Security Top 10であり、OWASPは定期的に改訂しているため、要約ではなく現行版を確認してください。

画面が見せている以上のものを返してしまう。 都合がよかったという理由でエンドポイントがユーザーオブジェクト全体を返し、フロントエンドはそのうち三つのフィールドを表示します。残りの十二、たとえばパスワード再設定用のトークンや内部のリスクスコアは、応答の中に残ったままです。ネットワークタブを開いた人は誰でもそれを手にします。シリアライズは意図的に行い、モデルをそのまま流すのではなく、名前を挙げたフィールドから応答を組み立ててください。

入口での一括代入。 これはちょうどその鏡像です。プロフィール更新のエンドポイントが、届いたフィールドを何でも受け取ってレコードに書き込むため、呼び出し元が "role": "admin" を添えるだけで自分を昇格させられます。リクエストボディを丸ごと受け入れるのではなく、許可したフィールドの一覧へ明示的にバインドしてください。

消費量に制限がない。 制限がなければ、ひとりの呼び出し元が1ページあたり百万件を要求し、重い検索をループで走らせ、パスワード再設定を数千件発火させることができます。これはサービス妨害だけの話ではありません。エンドポイントの背後に言語モデルがある場合のように、リクエストごとに費用が発生するのであれば、これは課金への攻撃です。レート制限は利用者ごと、エンドポイントごとに置き、費用の高い操作は安い操作よりも厳しく絞ってください。

棚卸しと第三者への信頼

文書化されていない、忘れられたエンドポイント。 バージョン2が稼働して文書化されている一方で、バージョン1は古い認可ロジックのまま動き続け、本番データを持つステージング用のAPIがインターネットから到達できる。攻撃者はまさにこれを探しています。配備されているすべてのAPI、すべてのバージョン、すべての環境の一覧を保ち、放置ではなく意図をもって廃止してください。

呼び出す先のシステムを信用してしまう。 あなたのAPIは他のAPIを消費し、その応答はあなたのデータベースと画面描画に流れ込みます。取引先だから安全だと仮定せず、返ってきたものを検証してください。信頼できる相手の障害や仕様変更が、そのままあなたの側の欠陥として表面化することは珍しくありません。同じ関係の信頼性の側面は、外部API連携 の解説で扱っています。

認証を正しく行うために

認証は、たいていのチームがおおむね正しくできている部分です。だからここでは、それを台無しにしてしまう細部を扱います。

有効期限のない長命な鍵ではなく、更新のできる短命なアクセストークンを使ってください。永遠に有効な資格情報が漏れれば、それは恒久的な侵害です。十五分で失効するものが漏れたのであれば、終わりの見えているインシデントにすぎません。

トークンの権限は狭く区切ってください。レポート連携のために発行されたトークンで、利用者を作成できてはいけません。スコープがあれば、各ハンドラーの確認に頼るのではなく、中央でそれを強制できます。

トークンの検証は正しく行ってください。これはほとんどの場合、トークン自身が名乗るアルゴリズムを受け入れない、という意味です。期待する署名アルゴリズムを固定し、発行者と対象者を検証し、有効期限を確認します。これらを既定で行うライブラリは存在します。間違いが住み着くのは、手で書いた検証のほうです。

資格情報は計画的に更新し、利用者が停止なしで切り替えられる手段を用意してください。通常は移行期間中に二つの鍵を同時に有効にします。更新が障害を招くのであれば、誰も更新しなくなります。

最後に、資格情報をURLに入れてはいけません。クエリ文字列はサーバーのログ、ブラウザーの履歴、プロキシのログ、リファラーヘッダーに残ります。ヘッダーを使ってください。

ペネトレーションテストが実際に見つけるもの

自動スキャンと手動テストは、見つけるものが異なります。理由も異なるので、両方が必要です。

スキャナーは、既知の脆弱な依存関係、欠けているセキュリティヘッダー、TLSの設定不備、明白なインジェクションを見つけるのが得意です。安価で、後戻りを検出してくれるので、パイプラインの中で継続的に走らせてください。

できないのは、あなたの業務について考えることです。割引コードのエンドポイントを繰り返し呼べば割引が積み上がる、有料機能が無料プランからAPIを直接叩くだけで使える、出荷後に注文を取り消すと在庫確認なしに返金が走る。テスターが見つけるのはこうしたものであり、実際にお金を失わせるのもこうしたものです。そしてこれは、そのAPIが何のためにあるのかを理解している人がいるときにしか表に出てきません。

APIに限って言えば、役割をまたいだ認可テストを含めるよう依頼してください。つまり、テスターが二つの異なる顧客の資格情報を持ち、一方のトークンでもう一方のアカウントのデータに到達できないかを体系的に試すということです。この一つの作業が、ほかのすべてを合わせたよりも多くを見つけます。ペネトレーションテストの種類 についての記事は、テスターにどこまでアクセスを渡すべきかを整理しています。文書と資格情報を渡したほうが、手がかりのないテストよりもはるかに良い結果になります。

予算の話をすると、API中心のテストはおおむね、小規模でよく文書化されたAPIで£3,000程度から、役割と連携が複数ある大きな面では£15,000以上になります。ペネトレーションテスト費用のガイド が、この幅を動かしている要因を分解しています。

調査できるだけのログを残す

インシデントと大惨事を分けるのは、たいていの場合、何が起きたのかを後から再構成できるかどうかです。

認証のイベント、認可の失敗、そして状態を変えるすべての操作を、呼び出し元の識別子、対象オブジェクト、相関識別子とともに記録してください。とくに認可の失敗は早期警報になります。正当な連携はこれをほとんど発生させないので、まとまった数が出ているなら、誰かが探りを入れているということです。

機微な値そのものは記録しないでください。トークン、カード情報、個人データがログファイルに入った瞬間、封じ込められていた侵害が報告義務を伴う侵害に変わります。

警報は量ではなくパターンに対して上げてください。ひとつの呼び出し元が多数のオブジェクト識別子にまたがって認可の失敗を出しているなら、それは列挙が進行中ということであり、人を起こす価値があります。エラー率の合計にはその価値はありません。

保存期間は、役に立つ長さにしてください。侵害は始まってから数週間後に見つかることが多く、三十日分のログでは侵入経路を突き止めるには短すぎることがよくあります。

実際に出荷したAPIをテストする

Mecanikはアプリケーションセキュリティテスト を提供しており、自動化されたツールが取りこぼす認可と業務ロジックの欠陥に重点を置いています。役割をまたいだ実際の資格情報による、アカウント横断のテストも含みます。

私たちは表面を推測するのではなく、仕様と文書から作業します。その副産物として、文書化されていないエンドポイントやバージョンの取り残しが見つかります。作業がインフラやネットワークのテストにまで及ぶ場合は、ペネトレーションテストサービス がその領域を扱います。まだAPIを設計している段階であれば、カスタムAPI開発の費用 の解説が、認可、レート制限、ログを後付けではなく構築の中のどこに置くべきかを整理しています。

仕様と役割の説明をお送りいただければ、リスクがどこに集中しているのかをお伝えします。

関連記事: 英国におけるペネトレーションテスト - 2026年に期待されること 、2026年における英国開発者向けGDPR技術的コンプライアンス 、Cloudflare Zero Trust：エンタープライズのアクセスセキュリティガイド 、経営者のためのOWASP Top 10 やさしい解説 。

よくある質問

APIで最も多いセキュリティ脆弱性は何ですか。 オブジェクト単位の認可の欠落です。認証済みの呼び出し元が、リクエスト内の識別子を変えるだけで他人のデータに到達できてしまう状態を指します。認証そのものは正しく動いていますが、要求されたオブジェクトが呼び出し元のものかを誰も検証していません。所有関係はクエリの中で強制する必要があります。

APIキーだけで十分な安全性が得られますか。 それだけでは足りません。有効期限のない長命な鍵は、一度漏れれば恒久的な侵害になります。更新のできる短命なアクセストークンを使い、利用者が実際に必要とする範囲にスコープを絞り、停止なしの鍵更新に対応し、URLではなく必ずヘッダーで送ってください。

自動スキャンだけでAPIを守れますか。 守れません。ただし継続的に走らせる価値はあります。スキャナーは既知の脆弱な依存関係、欠けているヘッダー、明白なインジェクションを見つけます。業務ルールについて考えることはできないため、割引の重ねがけ、無料プランから届いてしまう有料機能、アカウントをまたいだデータ参照は見逃します。

APIのペネトレーションテストの費用はどのくらいですか。 小規模でよく文書化されたAPIでおおむね£3,000程度から、役割と連携が複数ある大きな面では£15,000以上になります。費用を動かすのはエンドポイントの数、異なる役割の数、そして文書と資格情報が提供されるかどうかです。

セキュリティの目的でAPIは何を記録すべきですか。 認証のイベント、認可の失敗、そして状態を変えるすべての操作を、呼び出し元の識別子、対象オブジェクト、相関識別子とともに記録します。トークンや個人データは決して記録しないでください。ひとつの呼び出し元が多数の識別子にまたがって認可の失敗を出しているなら列挙の兆候であり、警報を上げる価値があります。