APIセキュリティレビューで実務で確認したい設計ポイント

APIセキュリティレビューは入口だけ見ても足りない

APIセキュリティレビューでよくある失敗は、ログインできるか、トークンを検証しているかだけを確認して終わることです。

もちろん、認証は重要です。しかし、実務のAPIでは認可、入力検証、情報露出、レート制限、ログの扱いまで確認しないと、事故を防ぎきれません。

例えば、ログイン済みユーザーだけが呼べるAPIでも、他人の注文IDを指定できるなら問題です。入力値をチェックしていても、エラーレスポンスに内部情報を出していれば調査材料を与えます。

この記事では、Java/Spring BootなどでREST APIを開発するエンジニア向けに、APIセキュリティレビューで確認したい設計ポイントを整理します。目的は、脆弱性診断だけに頼らず、日々の設計レビューやコードレビューで早めにリスクを見つけることです。

APIセキュリティレビューでまず見る全体像

まず、レビュー対象を「認証だけ」に閉じないことが重要です。APIは外部から直接呼ばれる境界です。そのため、設計の小さな抜けが情報漏えいや不正操作につながります。

OWASPのAPI Security Top 10 2023では、API特有のリスクが整理されています。Broken Object Level Authorization、Broken Authentication、Unrestricted Resource Consumptionなどは、実務レビューでも特に意識したい観点です。

レビューでは、次のように層を分けて確認します。

観点	確認すること	漏れると起きる問題
認証	誰が呼んでいるか確認できるか	未ログインや不正トークンで呼ばれる
認可	その人が対象リソースを操作できるか	他人のデータを参照、更新できる
入力検証	境界値、形式、許可値を検証しているか	想定外の値で処理が壊れる
出力制御	返してよい項目だけ返しているか	不要な個人情報や内部状態が漏れる
エラー	利用者向け情報と内部情報を分けているか	スタックトレースや実装詳細が漏れる
レート制限	高負荷や総当たりを抑えられるか	認証試行、検索API、外部連携が悪用される
ログ	調査に必要で、機密情報を含まないか	調査不能、またはログ経由の漏えいが起きる

この表は、レビュー時の入口として使えます。詳細な診断ではなくても、設計レビューの段階でかなりの抜けを見つけられます。

認証は「トークンを見ているか」だけで終わらせない

認証では、APIを呼んでいる相手を確認します。JWT、セッション、APIキー、OAuth 2.0など方式は現場によって違います。ただし、レビューで見るべきことは共通しています。

• 認証が必要なAPIに抜けがないか
• トークンの署名、有効期限、発行者、利用者を検証しているか
• ログアウト、無効化、権限変更後の扱いを決めているか
• 管理系APIと一般ユーザーAPIの境界が曖昧になっていないか

MDNのHTTP authenticationでは、認証に失敗した場合の401と、権限不足の場合の403が整理されています。APIレビューでも、認証失敗と認可失敗を混ぜないことが大切です。

例えば、期限切れトークンであれば401を返します。一方で、ログイン済みでも管理者権限がないなら403が自然です。全部を403や200で返すと、フロントエンドの共通処理や監視が複雑になります。

APIセキュリティレビューで最も漏れやすいのは認可

認可は、APIセキュリティレビューで特に漏れやすい観点です。ログイン済みであることと、対象データを操作できることは別問題だからです。

例えば、次のようなAPIがあるとします。

GET /api/orders/{orderId}
PUT /api/orders/{orderId}/shipping-address
DELETE /api/users/{userId}/sessions

このとき、ログイン済みかどうかだけでは足りません。注文IDが本人のものか。代理操作を許可する条件はあるか。管理者ならすべて見られるのか。こうした業務ルールを確認する必要があります。

Spring Security公式のAuthorizationでは、リクエストベースとメソッドベースの認可が説明されています。実務では、URL単位の大きな制御と、Service層でのリソース所有者チェックを組み合わせることが多いです。

レビューでは、Controllerに到達できるかだけでなく、Serviceで対象データを取得した後に所有者や権限を確認しているかを見ます。特にID指定の参照、更新、削除APIは重点的に確認します。

ロール権限だけでリソース所有者チェックを代用しない

ロール権限は便利です。ただし、USER、ADMINのようなロールだけでは、誰のデータを操作できるかまでは表現できません。

例えば、USERロールを持つ全員が `GET /api/users/{userId}` を呼べる設計では危険です。本人だけが見られるのか、同じ組織なら見られるのか、管理者だけ例外なのかを明確にします。

確認対象	レビューで見ること
URL単位の認可	未ログイン、一般ユーザー、管理者の入口を分けているか
リソース所有者	URLのIDとログインユーザーの関係を確認しているか
代理操作	代理操作できる条件と監査ログがあるか
管理者操作	権限が強すぎる管理者APIを分離しているか

入力検証はControllerだけでなく意味まで見る

入力検証では、形式チェックだけでなく、業務的に許される値かを確認します。文字列長、必須、数値範囲、日付形式は入口です。それだけでは足りません。

例えば、注文数量が1以上かを見るだけでは不十分です。在庫数を超えていないか。キャンセル済み注文を更新できないか。本人以外が住所を変更できないか。こうした意味の検証が必要になります。

Spring BootではBean ValidationでDTOの形式チェックを行い、Service層で業務ルールを確認する設計が扱いやすいです。レビューでは、次のように責務が分かれているかを見ます。

層	主な確認内容	例
Controller / Request DTO	形式、必須、長さ、型	メール形式、最大文字数、必須項目
Service	業務ルール、状態遷移、所有者	本人の注文か、更新可能な状態か
Repository / DB	一意制約、外部キー、整合性	重複登録、存在しないIDの参照

なお、入力値をログにそのまま出す設計にも注意します。検索条件、リクエスト本文、ヘッダーには、個人情報やトークンが含まれる場合があります。

エラーレスポンスは親切さと情報露出のバランスを見る

エラーレスポンスは、利用者に必要な情報を返しつつ、内部情報を隠す設計にします。ここは実務で判断が分かれやすいです。

例えば、入力エラーではどの項目が不正かを返すと、フロントエンドで表示しやすくなります。一方で、SQLエラー、クラス名、スタックトレース、内部IDを返す必要はありません。

{
  "code": "VALIDATION_ERROR",
  "message": "入力内容を確認してください。",
  "fields": [
    { "name": "email", "reason": "メールアドレスの形式が正しくありません。" }
  ],
  "traceId": "9f2b..."
}

このように、利用者向けメッセージと調査用のtraceIdを分けると扱いやすくなります。詳細な原因はサーバー側ログで追えるようにします。

レビューでは、404と403の使い分けも確認します。リソースの存在を隠したいAPIでは、権限がない場合にも404相当で返す設計があり得ます。ただし、システム全体で方針を決めておかないと、フロントエンドと運用が混乱します。

返却項目はAPIごとに必要最小限にする

APIセキュリティレビューでは、レスポンスの項目も確認します。Entityをそのまま返す実装は、不要な情報を返す原因になりやすいです。

例えば、ユーザー一覧APIで、画面に表示しないメールアドレス、電話番号、内部ステータス、削除フラグまで返していないでしょうか。今は画面に出していなくても、APIレスポンスとして返っていれば露出しています。

• 画面や連携先に必要な項目だけ返しているか
• 個人情報、権限情報、内部フラグを不要に返していないか
• 管理者向けレスポンスと一般ユーザー向けレスポンスを分けているか
• レスポンスDTOで返却項目を明示しているか

情報露出は、ログイン済みユーザー向けAPIでも起きます。特に一覧API、検索API、エクスポートAPIは、返却件数と返却項目の両方を確認します。

レート制限とリソース消費をレビューする

レート制限は、認証APIだけの話ではありません。検索API、ファイル生成API、外部サービス連携API、メール送信APIなども対象です。

例えば、検索条件を自由に指定できるAPIでページング上限がなければ、大量データを取得される可能性があります。パスワード再設定メールを無制限に送れるなら、迷惑メールやなりすまし調査の負担につながります。

API	確認したい制御
ログイン	失敗回数、IP、アカウント単位の制限
検索	ページサイズ上限、ソート対象、タイムアウト
ファイル生成	同時実行数、再実行間隔、サイズ上限
メール送信	送信回数、宛先制限、監査ログ
外部API連携	リトライ回数、サーキットブレーカー、タイムアウト

OWASP API Security Top 10でも、リソース消費の制御は重要なリスクとして扱われています。レビューでは、正常系の使いやすさだけでなく、悪用や高負荷時の振る舞いも確認します。

ログは調査できることと漏らさないことを両立する

セキュリティ事故や不正操作を調査するには、ログが必要です。一方で、ログに機密情報を出すと、それ自体が漏えい経路になります。

レビューでは、次の情報がログに残っているかを確認します。

• 誰が操作したかを追えるユーザーID
• どのAPIで失敗したかを追えるパスや処理名
• リクエスト単位で追跡できるtraceIdやrequestId
• 認証失敗、認可失敗、重要操作のイベント

反対に、パスワード、アクセストークン、リフレッシュトークン、APIキー、クレジットカード番号、個人情報をそのまま出してはいけません。マスキング方針を決め、共通処理で守る設計が必要です。

特にエラーログは注意します。例外オブジェクトやリクエスト本文を丸ごと出す実装は便利に見えます。しかし、本番では機密情報を含む可能性があります。

APIセキュリティレビューのチェックリスト

最後に、レビューで使いやすい形に確認点をまとめます。すべてのAPIで同じ深さに確認する必要はありません。個人情報、決済、管理機能、権限変更、外部公開APIは優先度を上げます。

分類	レビュー項目
認証	認証必須APIに抜けがないか。トークンの有効期限や署名を検証しているか。
認可	ロールだけでなく、リソース所有者や組織境界を確認しているか。
入力	形式チェックと業務ルールチェックの責務が分かれているか。
出力	レスポンスDTOで必要最小限の項目だけ返しているか。
エラー	内部情報を返さず、調査用IDで追跡できるか。
レート制限	総当たり、高負荷、大量取得を抑える制御があるか。
ログ	調査に必要な情報を残し、機密情報をマスクしているか。
運用	権限変更、退職、鍵ローテーション、インシデント時の手順があるか。

レビューで大切なのは、チェックリストを機械的に埋めることではありません。APIの用途、扱うデータ、外部公開範囲、利用者の権限を見て、どこにリスクが集中するかを判断します。

よくある質問

APIセキュリティレビューは脆弱性診断と何が違いますか？

APIセキュリティレビューは、設計やコードの段階でリスクを見つける活動です。脆弱性診断は、動くシステムに対して問題を確認する活動です。どちらか一方ではなく、設計レビュー、コードレビュー、診断を組み合わせると効果的です。

全APIにレート制限を入れるべきですか？

すべて同じ制限にする必要はありません。ただし、ログイン、検索、メール送信、ファイル生成、外部API連携のように悪用や高負荷の影響が大きいAPIは、優先して検討します。

認可チェックはControllerとServiceのどちらに書くべきですか？

URL単位の大きな制御はController到達前に行うと扱いやすいです。一方で、対象データの所有者や状態を見ないと判断できない認可はService層で確認します。入口の制御と業務ルールの制御を分けるのが実務的です。

まとめ：APIセキュリティレビューは設計の責務分離から始める

APIセキュリティレビューでは、認証だけでなく、認可、入力検証、出力制御、エラー、レート制限、ログまで確認します。

• 認証と認可を分けて考える
• リソース所有者チェックをロール権限だけで代用しない
• 入力、出力、エラー、ログで情報露出を防ぐ
• 高負荷や悪用を想定してレート制限を検討する

セキュリティは、最後にまとめて確認するより、設計とレビューの中に組み込む方が効果的です。特にJava/Spring BootでREST APIを扱う案件では、認可やログの設計まで説明できるエンジニアは現場で信頼されやすくなります。

API設計、認証認可、ログ設計、レビュー観点を整理しながら次の案件を考えたい場合は、現在の経験や志向をもとに相談できます。