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