この記事のポイント認証は「誰か」を確かめ、認可は「何をしてよいか」を決めます。ログインできた利用者でも、すべてのデータを読んでよいわけではありません。操作とデータの両方で、権限の確認が必要です。
01 認証の成功と、アクセスの許可を分ける
APIがトークンを受け取っていても、その利用者が要求したデータへアクセスできるかは別の判断です。画面にボタンを表示しないだけでなく、API側で対象と操作の権限を確認する設計が必要です。
OWASPは、オブジェクトごとの権限確認の不備をAPIの主要なリスクとして挙げています。識別子を推測しにくくしても、アクセス権限の確認そのものを省略する理由にはなりません。
02 操作・データ・利用者の組み合わせを整理する
相談の準備として、利用するAPI、扱う情報、想定する利用者を一覧にします。「参照は可能、更新は管理者のみ」のように、期待する動作を言葉にすると検査範囲を定めやすくなります。
- HTTPメソッドとパス、操作の目的
- 扱うテストデータと、その所有者
- 公開APIか、テスト用認証が必要か
- 利用者・管理者など権限の違いと、期待する結果
03 標準診断に含まれる範囲を確認する
PENVISTAのAPI診断では、指定された操作の入力・応答、提供されたOpenAPI定義、対象方式に応じた認証設定を確認します。検証環境とテスト用の情報を使います。
全権限を組み合わせた認可検証や業務フローの悪用検証は、標準範囲に含まれません。この記事で説明する認可の課題まで調べたい場合は、必要な検証範囲を相談時に明示してください。
04 検査結果を修正へつなぐ
期待するアクセス条件と実際の応答を照らし合わせ、修正担当者へ共有します。変更した認可処理がほかの操作に影響しないかも、開発側で確認する必要があります。
診断後に機能や権限を追加した場合は、その変更が以前の確認範囲に含まれているかを見直します。診断結果は、実施した時点・条件とセットで扱ってください。
参考資料
技術や運用の考え方は以下の資料も参照してください。PENVISTAの提供範囲・料金は、当サイトのサービス案内と販売条件に従います。