大手サイバーセキュリティー企業Wallarm（ワラーム）は、最も一般的なAPI脆弱性の一つである認証の不備のまん延を指摘している。この問題は、アプリケーションセキュリティーに関する議論やセキュアコーディングガイドラインで頻繁に議論されており、OWASP Top 10にも含まれている。BOLA（オブジェクトレベル認証の不備）とBFLA（関数レベル認証の不備）は、四半期ごとに多数のAPI脆弱性の原因となっている。
2026年のAPI ThreatStatsレポートによると、認可の問題はAPIトップ10の脆弱性の中で9番目に多いものだ。この順位は、組織が大規模なロールと権限の管理において直面する継続的な課題を反映している。セキュリティーチームと開発チームは認可の不備を認識しているが、認可ロジックは本番環境導入前に立てられた前提に基づいてのみ信頼できるものであることを認識していない人が多くいます。APIが実際のユーザー、データ、統合、自動化に公開されると、これらの前提が不十分であることが判明することがよくある。
Wallarmは、認証はしばしば多くの注目を集める一方で、認可も同様に、あるいはそれ以上に重要であると指摘している。認証は一元化、標準化され、監査可能であり、OAuthスコープ、トークンの有効期間、MFAポリシーといった成熟した制御が整備されている。一方、認可はアプリケーションロジックに埋め込まれており、エンドポイント、メソッド、パラメーター、ワークフローに分散している。この複雑さは、予測可能なパスや忘れられたHTTPメソッドを通じて、より高い権限を必要とする機能が露出する可能性があるため、BFLAの脆弱性につながることがよくある。
Wallarmは、強力な認証が必ずしもAPIの安全性につながるわけではないとも解説している。認証はユーザーの身元を確認するだけであり、認可はユーザーがどのようなアクションを、どのオブジェクトに対して、どのような条件下で実行できるかを決定する。このロジックははるかに脆弱であり、脆弱性が生じやすいのです。
Wallarmはさらに、認可ロジックはビジネスロジックと密接に結びついていると説明している。BOLAの脆弱性は、APIがアカウント、ドキュメント、トランザクションIDなどのオブジェクト識別子を、所有権やアクセス権を継続的に検証せずに受け入れる場合に発生する可能性がある。この問題は理論上は簡単に対処できるように思えるかもしれないが、実際には、機能が進化し、新しいアクセスパスが追加され、バックグラウンドジョブや統合によってエンドポイントが予期せぬ方法で再利用されるにつれて、より複雑になる。
同社はまた、攻撃者が有効な認証情報でログインし、正当なトークンを取得し、API仕様に準拠したリクエストを発行することで、「機能している」認証を悪用するケースが多いと警告している。さらに、オブジェクトIDを操作したり、予測可能なパスやメソッドで特権機能にアクセスしたり、ワークフロー全体にわたってエンドポイントを連鎖させてアクセス権限を昇格させたり、人間では不可能な速度で列挙を自動化したりすることで、認証のギャップを悪用する。
Wallarmは最後に、セキュリティーリーダーに対し、認可へのアプローチを見直すよう助言している。機能のリリース後に認可を「完了」とみなすのではなく、認可の結果を継続的に監視し、有効な認証情報が悪用されることを想定する必要がある。また、成功は、データの漏洩防止、ロジックの悪用阻止、ビジネスへの影響回避など、何が起こらなかったかによって評価されるべきだと提言している。
APIセキュリティーは常に進化を続けており、Wallarmは設計時の信頼性から実行時の確実性へと移行することの重要性を強調している。APIセキュリティーの未来は、誰がログインするかではなく、その後に何が起こるかに大きく左右されると彼らは主張している。
出典：Wallarm
この製品の詳細については、Wallarm製品ページをご覧ください。
