認可バイパスで、他ユーザーのデータ・機能へ到達できる
IDを差し替えるだけで他ユーザーのデータへ到達でき、要求の形は正常に見えます。権限の異なる利用者を並べて同じ経路を呼ばないと見つかりません。
GENZ, Inc.
API公開・外部
API公開・外部連携向け
APIの脆弱性診断
連携先から求められるセキュリティ要請に対し、認可や認証、データ露出といったAPI固有のリスクが残っていないかを手動診断まで含めて確かめます。
支援事例
支援実績5,000件以上
APIでよくあるセキュリティ不備
外部公開したAPIの不備は、認可や認証の判定、レスポンス項目の設計、リクエスト頻度の制御、API資産の管理に集まります。漠然とした不安のままにせず、診断の対象になる不備を、代表的な5つに分けて挙げます。
認可バイパスで、
認証・トークン管理の穴で、なりすましを許してしまう
パスワードの条件に加え、失効させたトークンや使い回された更新用トークンを拒めない状態が残ると、漏えいに気づいた後も長くなりすましが続きます。
過剰なデータ露出やマスアサインメントで権限を昇格される
画面で隠しても応答の中身には内部項目が残ります。許可する項目を明示していない実装では、想定外の項目を混ぜた要求で権限の項目まで書き換えられます。
レート制限がなく、大量アクセスや不正ログインを許す
上限ぎりぎりでの連続要求や、認証の前後での適用差が抜け穴です。経路ごとにしきい値と超過時の応答を確かめないと、総当たりが平常の通信に埋もれます。
棚卸しされていないAPIがSSRFなど攻撃の起点になる
停止の告知と実際の停止が食い違うと、廃止した旧版が古い認証設定のまま生き続けます。台帳に載らない経路も保護から外れ、外部URLの中継に使われます。
脆弱性が残存することで起きる問題
これらの不備は、技術的な問題のままでは終わりません。連携先との取引や進行中の商談、事業の継続まで影響が連鎖していきます。
診断時におさえるべきセキュリティ観点
ツールの網羅チェックだけでは、APIの権限設計に沿った判断まで届きません。国際的なAPIの脆弱性分類、業界団体が示すAPI接続時のチェック項目、クラウド基盤の提供元が示すAPI保護指針をふまえ、次の5点で読み解きます。
他ユーザーのデータ・機能への到達を防ぐ
権限設計とオブジェクトレベル認可制御の検証
API仕様書と権限一覧から役割ごとに呼び出せる範囲の期待値を作り、権限の異なる利用者でエンドポイントとオブジェクトを総当たりで突き合わせます。画面に出ていない管理者向けの経路も対象に含めます。
確認する資料
- API仕様書
- 権限一覧
失効させた資格情報でのなりすましを防ぐ
認証方式とトークン・セッション管理の検証
認証方式に加え、アクセストークンの発行と失効、リフレッシュトークンのローテーション、多要素認証の設計を認証フロー仕様と突き合わせます。失効させた資格情報が使えないかまで確認します。
確認する資料
- 認証フロー仕様
内部項目の露出と権限項目の書き換えを防ぐ
APIレスポンスの過剰項目とパラメータ制御の検証
レスポンスに載る項目の過不足と、パラメータの書き換えを受け付ける範囲を、APIレスポンス定義と照合します。外部へのリクエストを代行させるサーバー側リクエスト強要の余地も、設計段階でたどります。
確認する資料
- APIレスポンス定義
大量アクセスと総当たりの通過を防ぐ
リクエスト頻度制御とレート制限設定の検証
エンドポイント単位のレート制限とスロットリングの設計を、利用シナリオと想定トラフィックに照らします。バーストとクォータの二段制御が働くしきい値まで調べます。
確認する資料
- パラメータ設定書
台帳にない旧版APIが起点になるのを防ぐ
API資産の棚卸しと外部連携経路の安全性検証
公開中のAPIをAPI一覧とAPI定義から突き合わせ、定義に載っていない経路が残っていないかを点検します。連携先一覧と照らし、資産管理の不備が外部連携経路のどこに出るかも設計書の上で確かめます。
確認する資料
- API一覧・API定義
- 連携先一覧
診断の進め方・具体的な診断内容
観点を、予算と期限のなかで実行できる診断計画へ落とし込みます。棚卸しから報告書の受け渡しまでの進め方は、次の4つです。
STEP 01
対象API・エンドポイントを棚卸しし、優先範囲へ絞り込む公開・連携中のAPI資産を一覧化
どう確かめるか
対象API・エンドポイントを棚卸しし、優先範囲へ絞り込む
公開中と連携中のAPI資産の棚卸しから始め、エンドポイントを一覧にします。連携先の要件と回答の期限、公開範囲と業務影響を照らし、どこから診断するかの優先範囲を合意したうえで着手します。
- 01公開中と連携中のAPI資産を棚卸しする
- 02エンドポイントを一覧にし公開範囲を確かめる
- 03連携先の要件と期限から優先範囲を合意する
OUTPUTAPI資産一覧（優先範囲つき）
STEP 02
ツール診断と手動診断で、網羅と深掘りを両立する網羅はツール・深掘りは手動で
どう確かめるか
ツール診断と手動診断で、網羅と深掘りを両立する
ツールは、他人の識別子へ書き換えるだけの正常な形の要求を取りこぼします。この判定と業務ロジックはAPI仕様を読み込んだ手動診断へ回し、ツール側は既知のパターンの検出に絞ります。
- 01既知の型はツールで網羅的に診断する
- 02業務ロジックと認可の判定は手動で確かめる
- 03API仕様を読み込み正常な形の要求を試す
OUTPUT診断ケース一覧（手動・ツール別）
STEP 03
検出した脆弱性を、リスクと優先度で整理する深刻度と悪用しやすさで順序化
どう確かめるか
検出した脆弱性を、リスクと優先度で整理する
深刻度の区分と影響範囲に加え、自社の構成での悪用しやすさを見て順序を決めます。境目付近は判断が割れるため、受容の判断基準を先に合意し、修正・緩和・受容を是正計画へ落とします。
- 01深刻度の区分と影響範囲を突き合わせる
- 02自社の構成での悪用しやすさを見積もる
- 03受容の判断基準と判断者を先に合意する
OUTPUT是正計画（優先度つき）
STEP 04
診断報告書の共有から是正・再診断まで伴走する再現手順と是正優先度を整理
どう確かめるか
診断報告書の共有から是正・再診断まで伴走する
再現手順と是正の優先度をまとめた報告書を共有し、連携先審査や商談の場に持ち込める形でお渡しします。是正後の再診断まで含めて、対応が終わるところまで伴走します。
- 01検出ごとに再現手順を記録する
- 02修正・緩和・受容の優先度を整理する
- 03是正後に確かめる範囲と条件を書き添える
OUTPUT診断結果記録（再現手順つき）
私たちGENZが、このようなAPIの脆弱性診断を代行します
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったセキュリティエンジニアが、第三者の視点で診断するメリット
- 開発側の思い込みや先入観に影響されず、設定や実装の不備を検出できる
- 診断観点にもとづく網羅的な検査で、見逃しを減らせる
- 開発チームが診断の工数から解放され、開発に専念できる
APIの公開・連携段階に寄り添う脆弱性診断
GENZは、開発ベンダーや情報システム部門と役割を分け、第三者として診断の計画から報告、是正の確認までを担います。フルメニューを一律におすすめせず、範囲と優先順位を合意しながら、次の4点をお引き受けします。
連携範囲・優先度に合わせた段階的提案
連携の範囲と優先度に合わせ、予算や連携スケジュール、審査の期限に収まる小さな範囲から始められます。
再現手順と是正優先度を示す診断報告書
検出した内容を再現手順と是正の優先度まで書き下し、チェックシートの回答や連携審査、商談の説明材料に使えます。
是正後の再診断まで対応
是正後の再診断は、範囲と条件を取り決めたうえで対応します。診断の対象はAPIからWebアプリ、ネイティブアプリまでの全領域です。
ソフトウェアテストと同じ窓口で頼める
API脆弱性診断と機能テスト、第三者検証、負荷テストをひとつの窓口で完結でき、発注や進行の調整にかかる負荷が下がります。
ご相談から納品までの流れ
対象範囲と判断基準を先に合わせ、進捗と残るリスクを共有しながら進めます。
ヒアリングで対象範囲を具体化する
対象システム、拠点、扱うデータ、連携先、業務フロー、リリース時期を確認し、未検証領域を可視化します。
診断計画と優先順位を合意形成
事故影響、変更量、利用頻度、代替手段の有無から優先順位を定め、必要な工数と計画を具体化します。
診断実施と進捗・課題を毎回共有
実施状況、発見事項、阻害要因、追加確認が必要な仕様を共有し、終盤のまとめ出しを避けます。
報告書納品と再診断支援まで実施
診断完了レポートに結果、証跡、未実施範囲、残留リスクを整理し、修正後の再診断条件まで引き継ぎます。
5,000件以上の対応実績
APIの診断範囲・優先順位を、GENZに相談する
ご相談では、診断の対象となるAPIの範囲、着手の優先順位、必要工数の考え方、機能テストや負荷テストなど関連するテストの要否まで、一緒に整理できます。