OWASP API Security Top 10 2023の全10項目｜APIセキュリティのガイドラインと対策

OWASP API Security Top 10は、Webアプリ全般を対象とするOWASP Top 10とは別に、API固有のリスクを10項目にまとめた啓発文書です。現行版は2023年6月5日に安定版が公開された2023年版で、2019年版に続く第2版にあたります。この記事では、API1:2023からAPI10:2023までの中身と公式の防止策、2019年版からの変更点を整理します。あわせて、デジタル庁のAPIテクニカルガイドブックや全国銀行協会の報告書など国内のAPIセキュリティガイドラインがどこまで扱っているか、どこをOWASP側で補うべきかも説明します。APIセキュリティの全体像から知りたい場合はAPIセキュリティの主要リスクと実装対策の解説を先に読んでください。

まとめ：OWASP API Security Top 10 2023と国内ガイドラインの要点

• 2026年9月時点の現行版は2023年版です。公式リポジトリの直近の更新は各国語への翻訳追加で、次の版に向けた作業は確認できません。
• 10項目のうち3つ（API1・API3・API5）が認可の不備です。オブジェクト単位、プロパティ単位、機能単位のそれぞれで「その利用者に許可されているか」を毎回サーバー側で確かめることが対策の中心になります。
• 2023年版の順位は、発生件数の統計ではありません。2022年に3か月間データを公募したものの統計分析に使えるデータが集まらず、専門家のレビューとコミュニティの意見で決めています。
• デジタル庁「APIテクニカルガイドブック」（DS-464-2、2024年9月30日版）のセキュリティ対策表は、TLS、APIキーまたはOpenID Connectによる利用者認証、利用制限、CORSが中心で、オブジェクト単位の認可の項目はありません。この表だけではAPI1の認可チェックを具体化できないため、OWASPとASVSの要件も照合します。
• Top 10はチェックリストではなく啓発文書です。実装の合否を確かめるときは、ASVS 5.0.0の検証要件（BOLAなら8.2.2）を使います。

OWASP API Security Top 10 2023の成り立ちと最新版の状況

2023年版の順位決定：データ公募の結果と専門家の評価

2023年版のリリースノートは、2019年の初版からちょうど4年後の第2版だと説明しています。この版では初めて一般からのデータ公募（Call for Data）を2022年9月1日から11月30日まで実施しました。しかし公式の方法論ページは、統計分析に使えるデータは集まらなかったと明記しています。

そのため順位は、2019〜2022年に報告されたバグバウンティや公開レポートの事例、専門家との議論、リリース候補へのコミュニティの意見をもとに決められました。リスク評価の説明にも、この版はデータ駆動ではなく、発生頻度（Weakness Prevalence）の値はチームの合意で決めたとあります。280万件超のアプリのデータを集計したOWASP Top 10 2025年版とは作り方が違うので、「API1が最も多く発生している」と読むのは誤りです。自社で優先順位を付けるときは、順位ではなく自社APIの構成（オブジェクトIDを受け取るエンドポイントがいくつあるか、外部APIをいくつ呼んでいるか）を基準にしてください。

2019年版からの統合・新設・削除の対応

2023年版では2項目の統合と3項目の新設があり、Injectionと、ログとモニタリングの不備の2項目がリストから外れました。

API3の統合について、リリースノートは「過剰なデータ露出」と「マスアサインメント」の根本原因がどちらもプロパティ単位の認可検証の失敗だからだと説明しています。API6の新設は、レート制限で緩和できる脅威の多くをこの項目に集める意図です。API10は、攻撃者が標的のAPIを直接狙わず、連携先のサービスを先に攻略する動きが見え始めたことへの注意喚起として加えられました。Injectionが外れたのは対策が不要になったからではありません。公式の方法論ページは、InjectionはAPIにも存在するものの、APIだからといって挙動も悪用方法も変わらない汎用的なリスクなので載せなかったと説明しています。Web全般のInjectionはOWASP Top 10 2025年版の10項目と2021年版からの変更点で扱われています。

次の版の動きと日本語訳の有無

公式の方法論ページは、2023年版を「今後3〜4年を見据えた啓発文書」と位置づけています。2026年はその期間の終わりにあたりますが、GitHubのOWASP/API-Securityリポジトリで2026年9月に入った変更はヒンディー語・スペイン語などの翻訳追加で、次の版の候補リストやデータ公募の告知は見当たりません。

2023年版の翻訳は、公開中のmasterブランチでは英語・フランス語・インドネシア語・ペルシャ語・ポルトガル語（ポルトガル）の5言語、作業中のdevelopブランチではスペイン語・ヒンディー語・イタリア語・トルコ語が加わった9言語です。どちらにも日本語版はありません。日本語で読める公式訳が無いため、項目名の和訳は記事や製品ごとに揺れます。社内文書では「API1:2023 BOLA」のように番号と英語略称を併記すると、参照先を取り違えずに済みます。

API1〜API10の一覧と公式の防止策

和訳は本記事での訳です。項目名と防止策は、OWASP公式の2023年版にある各項目の「How To Prevent」を参照しています。

認可の3項目（API1・API3・API5）の実装対策

10項目のうち3つが認可の不備で、しかもAPI1が1位です。認証（誰であるか）が正しくても、認可（その人に何を許すか）が抜けていれば他人のデータを読めてしまいます。IDORや権限昇格の攻撃手口は認可バイパスとIDOR・権限昇格の仕組みとサーバ側の対策で詳しく扱っています。

API1 BOLA：IDの推測困難さに頼らないオブジェクト単位の権限確認

BOLAは、/invoices/inv_1002のようにクライアントから受け取ったIDでデータを取り出すとき、ログイン中の利用者に、そのデータへの要求された操作が許可されているかを確かめていない状態です。公式の防止策は、クライアントの入力を使ってデータベースのレコードにアクセスするすべての関数で、ログイン中の利用者がその操作をしてよいかを認可の仕組みで確認することです。

// API1: 所有者本人だけに閲覧を許す例。currentUser は認証済みの利用者情報
const invoices = new Map([
  ["inv_1001", { id: "inv_1001", ownerId: "u_alice", amount: 12000 }],
  ["inv_1002", { id: "inv_1002", ownerId: "u_bob", amount: 98000 }],
]);

function getInvoice(currentUser, invoiceId) {
  const invoice = invoices.get(invoiceId);
  // 存在しない場合と他人の請求書の場合を同じ応答にし、IDの存在を推測させない
  if (!invoice || invoice.ownerId !== currentUser.id) {
    return { status: 404, body: { error: "not_found" } };
  }
  return { status: 200, body: invoice };
}

console.log(getInvoice({ id: "u_alice" }, "inv_1001").status); // 200
console.log(getInvoice({ id: "u_alice" }, "inv_1002").status); // 404

Node.js 26.5.0で実行すると、1行目は200、2行目は404を出力します。公式の防止策には「レコードのIDにはランダムで予測できない値（GUID）を使う」という項目もありますが、GUIDだけでは対策になりません。2026年8月25日に公式リポジトリのdevelopブランチへ入った注記は、IDが別のエンドポイントやログなどから一度漏れたら公開情報として扱うべきであり、認可の判断をIDの秘匿性や予測困難さに頼ってはならないと明記しています（2026年9月時点で公開サイトには未反映）。連番をUUIDに替えたことでBOLA対策を済ませたと判断するのは誤りです。

API3 BOPLA：返す項目と書き換えられる項目の許可リスト

BOPLAは、オブジェクトそのものへのアクセスは正しくても、その中の個々のプロパティ（項目）単位の認可が抜けている状態です。応答にpasswordHashのような内部項目が載る「過剰なデータ露出」と、リクエストにisAdmin: trueを混ぜると書き換わる「マスアサインメント」が典型です。公式の防止策は、to_json()のような汎用メソッドで丸ごと返さず必要な項目だけを選ぶこと、クライアントの入力を内部オブジェクトへ自動で束縛する機能を避けること、クライアントが更新してよい項目だけ変更を許すことです。

// API3: 受け取る側も返す側も、プロパティを許可リストで絞る
const WRITABLE = ["displayName", "email"];
const READABLE = ["id", "displayName", "email"];

const pick = (obj, keys) =>
  Object.fromEntries(keys.filter((k) => k in obj).map((k) => [k, obj[k]]));

function updateProfile(user, requestBody) {
  Object.assign(user, pick(requestBody, WRITABLE)); // isAdmin 等は無視される
  return pick(user, READABLE); // passwordHash 等は応答に載らない
}

const user = { id: "u_alice", displayName: "Alice", email: "[email protected]",
               isAdmin: false, passwordHash: "x" };
console.log(updateProfile(user, { displayName: "Alice2", isAdmin: true }));
console.log(user.isAdmin);

実行すると、応答はid・displayName・emailの3項目だけになり、user.isAdminはfalseのままです。拒否リスト（isAdminを除く）方式にすると、あとから列を追加したときに漏れます。許可リストで書くのはそのためです。画面に出していない氏名やメールアドレスが応答に載っていた国内の実例と、リリース前に応答を検査するテストはOfferBoxの情報漏洩とAPI応答の過剰なデータ露出で解説しています。

API5 BFLA：管理機能を既定で拒否する認可モジュール

BFLAは、一般利用者がDELETE /api/admin/users/42のような管理者向けの機能を呼べてしまう状態です。画面にボタンが無くても、APIの経路名やHTTPメソッドを推測されれば呼び出されます。公式の防止策は、すべての業務機能から呼ばれる一貫した認可モジュールを置き、既定ですべて拒否して機能ごとに役割へ明示的に許可を与えることです。管理用のコントローラーは認可チェックを持つ抽象コントローラーを継承させ、通常のコントローラーに混ざった管理機能にも個別に役割チェックを入れます。

認証・リソース・業務フローの3項目（API2・API4・API6）

API2 認証の不備：利用者認証とAPIクライアント認証の区別

公式の防止策には「OAuthは認証ではなく、APIキーも認証ではない」という一文があり、APIキーは利用者の認証には使わず、APIクライアント（アプリ）の認証だけに使うべきだとしています。パスワード再設定のエンドポイントはログインと同じ強さで総当たり対策・レート制限・ロックアウトを掛けること、メールアドレスや二要素認証の電話番号の変更には再認証を求めることも挙げています。方式の選び方とトークンの寿命はAPI認証の方式選定とトークン寿命の決め方、キーの発行から失効まではAPIキーの発行・保管・失効とローテーションで扱っています。

API4 リソース消費：レート制限だけでなくサイズと支出の上限

2019年版の「リソース制限とレート制限の不足」から名前が変わり、対象がCPUやメモリだけでなく、1件ごとに課金されるSMS送信やメール送信、生体認証などの外部サービスにまで広がりました。攻撃の結果はサービス停止だけでなく運用費の増加にもなります。公式の防止策は次のとおりです。

• 文字列の最大長、配列の最大要素数、アップロードファイルの最大サイズなど、すべての入力パラメータとペイロードに上限を決めて強制する
• 一定時間内の呼び出し回数を制限し、エンドポイントごとに厳しさを調整する
• ワンタイムパスワードの検証やパスワード再設定の要求など、単一の操作の実行回数も制限する
• 応答で返すレコード数を指定するパラメータ（limitなど）をサーバー側で検証する
• 連携する外部サービスすべてに支出上限を設定し、設定できない場合は請求アラートを設定する

API6 業務フロー：チケット購入やコメント投稿の自動化対策

API6は実装のバグが無くても起きるリスクです。チケットの購入やコメントの投稿のような正規の業務フローを、自動化によって大量に実行されると事業に害が出ます。公式は対策を2層に分けています。業務側で「過剰に使われると損害が出るフロー」を洗い出すことと、技術側で保護手段を選ぶことです。技術側の手段として、デバイスフィンガープリント、CAPTCHAなどの人間判定、「カート追加から購入完了まで1秒未満」のような人間離れした操作パターンの検知、Torの出口ノードや既知のプロキシからのアクセス遮断が挙がっています。開発者向けやB2BのAPIは保護が手薄になりやすいので、同じように対象へ含めてください。

外部接続と運用の4項目（API7〜API10）

API7 SSRF：URLを受け取るAPIの許可リスト

Webhookの登録先や画像URLの取り込みなど、利用者が指定したURLへサーバーがリクエストを送る機能で起きます。公式の防止策は、取得処理をネットワーク上で隔離すること、取得を許すオリジン・URLスキーム・ポート・メディアタイプを許可リストで限定すること、HTTPリダイレクトを無効にすること、実績のあるURLパーサーを使うこと、取得した応答をそのままクライアントへ返さないことです。クラウドのメタデータエンドポイントを狙う手口はSSRFの仕組みとクラウドメタデータ悪用の防御実装で扱っています。

API8 設定の不備：内部APIもTLS化と不要メソッドの停止

公式の防止策は、クライアントとAPIサーバーの間だけでなく、下流・上流のコンポーネントとの通信も、内部向けか公開向けかを問わずTLSで暗号化するよう求めています。各APIで受け付けるHTTPメソッドを限定して他を無効にすること、エラー応答を含む全応答のスキーマを定めて例外のスタックトレースを返さないことも挙げています。

API9 棚卸し：本番以外のホストと旧版APIの台帳

どのホストでどの版が動いているかを把握できていないと、古い版のAPIやデバッグ用のエンドポイントが残ったままになります。公式の防止策は、すべてのAPIホストについて環境（本番・ステージング・テスト・開発）、誰がネットワーク上でアクセスできるか（公開・社内・取引先）、APIの版を台帳にすることです。新しい版でセキュリティを改善したら旧版への影響を評価し、改善を移植するか旧版を早く止めるかを決めることも求めています。APIゲートウェイでの一元管理はAPI管理の仕組みとゲートウェイとの違いで扱っています。

API10 外部APIの利用：連携先の応答も入力として検証

開発者は、利用者の入力よりも外部APIから受け取ったデータを信用しがちで、検証が甘くなります。攻撃者はその隙を突いて、標的のAPIではなく連携先のサービスを先に攻略します。公式の防止策は、連携先を選ぶ段階でそのAPIのセキュリティ体制を評価すること、連携はすべてTLSで行うこと、連携先のAPIから受け取ったデータも使う前に検証・無害化すること、連携先がリダイレクトしてよい行き先を許可リストで管理し、リダイレクトを盲目的に追わないことです。

国内のAPIセキュリティガイドラインと補完する国際仕様

「APIセキュリティのガイドライン」を探すと、国内では府省庁や業界団体の文書が上位に並びます。ただし、扱っている範囲はOWASP API Security Top 10と一致しません。

デジタル庁 DS-464-2：利用者認証と利用制限が中心

DS-464-2の「表2-10 REST APIにおけるセキュリティ対策例」は、4つの観点で対策を示しています。通信の改ざん・盗聴防止としてTLS 1.3の採用とHSTS、情報漏えい防止としてAPIキーまたはOpenID ConnectによるAPI利用者認証、サーバー負荷の管理として利用者ごとの利用制限とキャッシュ、クロスドメイン通信の許可としてCORSです。行政手続を扱う場合や個人情報を扱う場合はOpenID Connectによる認証を推奨し、極めて守秘性の高い情報ではHybrid Flowを推奨しています。

APIキーについては「強固な対策ではない」と断ったうえで、パラメータに含めない、不要になったキーを削除するといった対応を求めています。これはOWASPのAPI2が「APIキーはクライアントの認証だけに使う」としている点と整合します。一方、この表にはオブジェクト単位・プロパティ単位の認可にあたる項目がありません。その他のリスクについては、IPA「ウェブサイトにおける脆弱性解説」とOWASPの「REST Security Cheat Sheet」を参照するよう案内しています。

全銀協の報告書とFISCのチェックリスト：接続先審査と技術的対策

全銀協が事務局を務めた検討会の報告書（2017年7月13日）の「セキュリティ原則」は、API接続先の適格性、外部からの不正アクセス対策、内部からの不正アクセス対策、不正アクセス発生時の対応、対策の継続的な改善・見直しの5つで構成されています。FISCの「API接続チェックリスト」は、金融機関とAPI接続先がセキュリティ対策を相互確認するための文書です。2025年12月版は9区分・44項目で、第8章「APIセキュリティ機能」は通番36〜42です。2017年6月公表の試行版を使っている場合は、おおむね1年以内に切り替えるよう求めています。

両文書は接続先の審査だけでなく技術的な対策も扱っています。全銀協の報告書3.3.2 gは、API接続先に付与するアクセス権限を提供サービスに必要な範囲へ限定し、利用者の同意があっても不要な権限は付与しないこと、トークンに適切な有効期限を設けること、不正アクセスの検知時に権限を速やかに制限・停止・取消できる仕組みにすることを求めています。ただし、これは銀行が接続先の事業者へ与える権限の範囲を定めたもので、APIの各エンドポイントが個々のオブジェクトや項目への操作を毎回確かめているか（API1・API3・API5）を検証する項目ではありません。

FISCのチェックリストは、BOLAにあたる攻撃を認識しています。通番37「APIの想定外利用を回避する」の注記は、想定外利用の例の1つ目に「URIの一部を改竄して、サーバにアクセスし不正に他社のデータを取得する」ことを挙げています。ただし手法例は、利用するAPIやトークンで実現できる機能を理解すること、外部団体のセキュリティリファレンスに則った認可機能を開発することにとどまり、リクエストごとの権限確認をどう実装し、どう検証するかまでは示していません。

国内ガイドラインだけでは足りない部分を埋める組み合わせ

国内の文書は「誰がAPIを呼べるか」（利用者認証・接続先の審査・権限の付与範囲・利用制限）を厚く扱っています。BOLAにあたる攻撃はFISCの通番37が例示していますが、「呼べる人が個々のデータや項目に何をしてよいか」をリクエストごとに確かめる実装要件と検証方法（API1・API3・API5）までは具体化していません。OWASPのリストで1位に置かれているのは、まさにこの後者です。社内のAPI設計基準を作るなら、通信・認証・利用制限はDS-464-2を下敷きにし、認可はOWASP API Security Top 10とASVSで補う組み合わせを勧めます。金融機関と接続するAPIや、高額の決済を扱うAPIでは、OAuthの実装をFAPI 2.0 Security Profileに合わせるかどうかも検討してください。

Top 10を検証要件へ落とすASVS 5.0.0の対応章

2023年版のリリースノートは、この文書を「将来を見据えた啓発文書」と呼んでいます。項目ごとに合否を判定する設計ではないため、Top 10をそのまま受け入れ基準や診断のチェックリストに使うと、何をもって「対応済み」とするかが決まりません。検証可能な要件に落とすには、同じOWASPのASVS（Application Security Verification Standard）を使います。2025年5月30日に公開されたASVS 5.0.0には、認可の3項目に直接対応する要件があります。

8.2.2の要件文は、特定のデータ項目への明示的な権限を持つ利用者にだけアクセスを制限し、IDORとBOLAを緩和することを求めています。8.1.1と8.1.2では、機能単位・データ単位・項目単位の認可ルールを文書に定義することも求めています。ASVS 5.0.0にはこのほか、V4「API and Web Service」（HTTPメッセージ構造の検証、GraphQLの高負荷クエリ対策と、外部利用を意図したAPIを除く本番環境でのイントロスペクション無効化、WebSocket）、V9「Self-contained Tokens」、V10「OAuth and OIDC」の章があります。API診断を外部に依頼するときは「OWASP API Top 10に準拠」ではなく「ASVS 5.0.0のV8・V4のレベル1要件に加え、BOPLA対策の8.2.3を検証する」のように章とレベルで指定すると、見積もりと結果の比較がしやすくなります。

よくある質問

OWASP API Security Top 10の最新版はいつの版ですか？

2026年9月時点では、2023年6月5日に安定版が公開された2023年版が最新です。2019年版に続く第2版で、2026年9月に公式リポジトリへ入った変更は翻訳の追加で、次の版の候補リストや公開予定の告知は確認できません。

OWASP Top 10とOWASP API Security Top 10は何が違いますか？

OWASP Top 10はWebアプリ全般のリスク、API Security Top 10はAPI固有のリスクを扱う別のリストです。作り方も違い、API Security Top 10 2023年版は統計に使えるデータが集まらず、専門家の合意で順位を決めています。

BOLAとは何ですか？

Broken Object Level Authorizationの略で、API1:2023の項目名です。クライアントから受け取ったIDでデータを取り出すときに、そのデータへのアクセス権を持つ利用者かどうかを確かめていないため、IDを書き換えるだけで他人のデータを読めたり変更できたりする状態を指します。IDをUUIDにしても、認可のチェックが無ければ防げません。

OWASP API Security Top 10に日本語版はありますか？

公式の日本語訳はありません。2023年版は英語・フランス語・インドネシア語・ペルシャ語・ポルトガル語などに訳されていますが、公式リポジトリに日本語のディレクトリはありません。項目名は番号と英語略称（API1:2023 BOLAなど）で参照するのが確実です。

APIのセキュリティ診断では何を確認すればよいですか？

まず認可の3項目（API1・API3・API5）を、利用者のIDや役割を入れ替えたリクエストで確かめます。検証項目はASVS 5.0.0の8.2.1〜8.2.3とV4「API and Web Service」を基準にすると範囲を明確にできます。あわせて、本番以外の環境や旧版のAPIが外部から呼べないか（API9）も確認してください。

関連記事

• APIセキュリティとは？OWASP API Top 10の主要リスクと実装対策を解説
• 認可バイパスとは？IDOR・権限昇格の仕組みとサーバ側で止める実装対策を解説
• API認証の設計｜方式選定マトリクスとトークン寿命・監査ログの決め方
• OWASP Top 10 2025年版とは？正式版の10項目と2021年版からの変更点
• OWASPとは？読み方・組織の実体と主要プロジェクトの全体像