【えーぴーあいせきゅりてぃ】

APIセキュリティ とは?

最終更新:
💡 データの窓口で、誰が何をできるか確かめる

アプリ同士の窓口であるAPIを、不正な利用やデータ漏えいなどから守る対策全般。認証・認可、入力の検証、通信の暗号化、利用量の制限や監視などを組み合わせる。

📌 このページのポイント
API:認証と権限を分けて確認アプリ注文を取得API側認証:誰か認可:操作できるかHTTPS通信を保護自分の注文許可された操作を通す他人の注文権限がなければ拒否ログイン済みでも、注文ごとに確かめる入力検証・利用量の制限も組み合わせる
注文APIの権限確認の例。公開APIの範囲や、認証・制限の置き場所は設計によって異なります。
ひよこ ひよこ
APIは、アプリの裏口なの?
ペンギン先生 ペンギン先生
APIはアプリ同士がデータや機能を使うための窓口だよ。公開して使ってもらうAPIもある。窓口自体が悪いのではなく、誰に何を許すかを決め、実際のリクエストで確かめることが大切なんだ。
ひよこ ひよこ
ログインしている人だけにすればいい?
ペンギン先生 ペンギン先生
認証で相手を確かめても、認可で権限を調べる必要があるよ。例えば自分の注文を読む人が、注文IDを変えて他人の注文も読めたら困る。対象データと操作に対する権限をAPI側で確認するんだ。
ひよこ ひよこ
それがBOLA?
ペンギン先生 ペンギン先生
そう。データ単位の権限チェックが壊れた状態を指すよ。画面で他人の注文へのリンクを隠しても、APIへ直接リクエストできる。ランダムなIDやログインの確認だけで解決したつもりにならないでね。
ひよこ ひよこ
HTTPSや回数制限も必要?
ペンギン先生 ペンギン先生
HTTPSは通信中の情報を保護するけれど、誰がデータを使えるかは別の確認だよ。入力の型や大きさの検証、レート制限なども組み合わせよう。回数制限は過剰な利用の影響を抑える対策で、あらゆる攻撃を防ぐものではないんだ。
ひよこ ひよこ
APIゲートウェイを置けば終わり?
ペンギン先生 ペンギン先生
認証や制限をまとめる助けにはなるけれど、各データの権限や業務の条件も必要だよ。API側で確認し、ログやテストで抜けを調べよう。OWASP API Security Top 10は、注意すべきリスクを整理する手掛かりになるね。
ペンギン
まとめ:ざっくりこれだけ覚えればOK!
「APIセキュリティ」って出てきたら「データや機能の窓口を不正な利用から守る対策」と思えばだいたいOK!
📖 おまけ:英語の意味
「API Security」 = API + セキュリティ
💬 そのまま「APIのセキュリティ」を意味する言葉だよ。特別な略語ではなく、対策分野全体を指す呼び方として定着しているよ。

参考資料

← 用語集にもどる