OWASP APIセキュリティの重大リスク10選

より優れたAPIセキュリティを実現するうえで、何から始めればよいか判断するのは難しいものです。「重大」と「重大ではない」脆弱性の違いや、バックエンドアプリケーション（つまりサーバー）やAPIを利用するその他のシステムに影響する深刻なリスクを軽減するため、どのツールを導入すべきか、チームで迷うこともあるでしょう。

サイバーセキュリティ業界では、こうした問いに応えるため、調査に基づく知見を提供し、優先すべきリスクやその対応方法を示すフレームワークを作成しています。最近登場したものの一つが、APIを保護するためのOWASP API Top 10です。

OWASP API Top 10とは

OWASP Foundationは10年以上にわたり、組織に向けたセキュリティの推奨事項を提供してきました。最もよく知られている取り組みは、2003年に始まり、2021年に更新されたOWASP Top 10プロジェクトです。

2019年、初のOWASP APIセキュリティリストが公開されました。OWASPがこのリストを公開したのは、APIの重要性と、今日のモバイル、SaaS、Webベースのアプリケーションのセキュリティ態勢に影響するリスクの高まりを認識したためです。

OWASP API Security Top 10を活用すべき理由

今日のソフトウェア企業は、APIなしではイノベーションを実現できません。APIは、サードパーティや社内の他の開発チームなど、さまざまな相手との容易な連携やデータ、機能の共有を可能にし、無数のアプリケーションの基盤となっています。つまり、APIの本質は、データを簡単に交換し、相互運用性を実現することです。しかし残念ながら、APIを通じて提供されるアプリケーションのロジックや機密データが攻撃者にさらされやすいということでもあります。APIは公開されている場合が多いため、悪意ある攻撃者に利用されるリスクは非常に高いのです。

WebアプリケーションセキュリティとAPIセキュリティの違い

OWASPがAPIの脆弱性トップ10を別に公開したのはなぜでしょうか。それは、APIとWebアプリケーションは相互に依存することが多いものの、明確に異なるテクノロジーであり、異なる種類のリスクをもたらすためです。

Webアプリケーションセキュリティ

従来のWebアプリケーションの主な入り口は、クライアント側とサーバー側の2か所です。一般に、Webアプリケーションに対する最大の脅威は、このいずれかに存在する弱点に関係しています。

アプリケーションにおけるOWASP Top 10の脆弱性の例として、サーバーに権限のない人がアクセスできてしまうアクセス制御の不備や、サーバー内のデータが適切に暗号化されていない暗号化の失敗が挙げられます。

このように、どちらのリスクもサーバーに直接関係しています。Webアプリケーションの入り口は限られているためです。データはサーバー側で処理され、Webページはクライアントのブラウザーで表示され、ユーザーがリクエストを送信すると、再びサーバーに届きます。これは単純な双方向の流れです。悪意ある攻撃者はそのどの部分にも介入できますが、入り口は限られています。

APIセキュリティ

一方、APIは多数のエンドポイントを公開しているため、攻撃者が機密データにアクセスできる可能性があり、攻撃対象領域が非常に広くなることがあります。単一のアプリ内のコンポーネントは、それぞれ個別のAPIを通じてサーバーとデータを送受信します。1つのアプリケーションに、攻撃者に悪用される可能性のある、クライアントに公開された入り口が数多く存在することもあります。

先ほど触れたように、APIの本質はデータを公開することです。APIが適切に機能すれば、他のアプリケーションやデータベースと「会話」できるため、アプリケーションの効率が大幅に向上します。しかし残念ながら、こうした性質によって、APIセキュリティのリスクは利用企業にとって特に深刻なものになります。

OWASP API Security Top 10を解説

OWASP API Securityリストは、アプリケーションサーバーのセキュリティを侵害する可能性が最も高い脆弱性をランキング形式で示しています。組織全体のAPIセキュリティを強化し、エンドツーエンドのセキュリティ態勢を向上させるソリューションやサービスを検討する際に、チームにとって優れた指針となります。

以下が全リストです。リンクから各項目に移動できます。

1. オブジェクトレベルの認可の不備

2. ユーザー認証の不備

3. 過剰なデータ露出

4. リソース不足とレート制限の不備

5. 機能レベルの認可の不備

6. 一括代入

7. セキュリティ設定ミス

8. インジェクション

9. 不適切な資産管理

10. ログ記録と監視の不足

#1: オブジェクトレベルの認可の不備

APIではオブジェクトレベルの認可を使用して、そのAPIが提供するデータに適切なユーザーだけがアクセスできるようにします。このアクセス制御の仕組みに不備があると、攻撃者はAPIを使って、自分が所有していない、またはアクセス権のないデータを開示、変更、削除できてしまいます。

#2: ユーザー認証の不備

強力な暗号鍵、パスワードスタッフィングの防止、強固なハッシュ化パスワードなど、十分なセキュリティ対策をAPIが使用していない場合、ユーザー認証のエンドポイントやフローに不備があると見なされます。開発者が鍵をローテーションしなかったり、トークン認証を設定しなかったりすると、攻撃者が他人の認証情報を入手し、それを使ってAPIにアクセスするおそれがあります。

たとえば、GitLabのソフトウェアには、スケジュール済みパイプラインで適切な認可が行われないバージョンが複数あります。この脆弱性により、悪意あるユーザーが別のユーザーになりすましてパイプラインを実行できる可能性があります。

#3: 過剰なデータ露出

この脆弱性は、APIが必要以上の情報を提供し、攻撃者に悪用される場合に発生します。開発者がエンドポイントを制限せずにAPIを汎用的に実装することが多いため、この種のデータ露出はよく見られます。公開するAPIエンドポイントを慎重に選び、それ以外はデフォルトでフィルタリングすることが重要です。

学習プラットフォームのMoodleがその一例です。Moodleのテーブルダウンロード機能では、非表示に設定された場合でも、テーブルにユーザーのメールアドレスが含まれます。この脆弱性は、簡単なアップグレードで修正できます。

#4: リソースの制限とレート制限の不足

クライアントがリクエストできるリソースのサイズや数に上限を設けていないと、脆弱性が生じます。適切なリクエストを送るまで無制限に「再試行」できる状況では、攻撃者がブルートフォース攻撃やサービス拒否（DoS）攻撃を仕掛ける可能性があります。

たとえば、`express-brute`ミドルウェアには、レート制限の回避に対して脆弱なパッケージがあります。リクエスト数のカウントが不適切だと、攻撃者がレート制限の仕組みを回避できます。

#5: 機能レベルの認可の不備

アクセス制御システムの設定に誤りがあると、攻撃者はAPIエンドポイントへの不正アクセス権を取得し、新たに得た権限を悪用できます。

マトリックスサーバーに必要な共通関数を提供するGoライブラリ、`github.com/matrix-org/gomatrixserverlib`には、権限レベルの解析関数が失敗するバージョンのパッケージがあります。その結果、Dendriteサーバーがイベントを誤って認可または拒否する場合があります。この脆弱性により、組織はサービス拒否（DoS）攻撃のリスクにさらされる可能性があります。

#6: 一括代入

この脆弱性は、APIがクライアントから提供されたデータをデータモデルにバインドするときに発生します。クライアント側に公開されたフィールドを改ざんするだけで、悪意あるクライアントがオブジェクトのプロパティを変更できてしまいます。

Webアプリケーションフレームワークのlaravel/frameworkがその一例です。このパッケージの影響を受けるバージョンでは、モデルで`fillable`プロパティを使用しない場合、一括代入の脆弱性が生じます。

#7: セキュリティ設定ミス

このカテゴリには、セキュリティ設定が正しく適用されていないことによって発生する脆弱性が含まれます。APIに影響するセキュリティ設定ミスの例は次のとおりです。

• セキュリティパッチの適用漏れ

• 不要な機能が有効になっている

• Transport Layer Security（TLS）またはCross-Origin Resource Sharing（CORS）ポリシーが使用されていない

• エラーメッセージに機密情報が含まれている

無料のオープンソースコンテンツ管理フレームワークである`typo3/cms`には、セキュリティ設定ミスの脆弱性があるバージョンが複数あり、認証情報が空のアカウントが作成される可能性があります。適切なアクセス権限を持つバックエンドユーザーが、この弱点を悪用するおそれがあります。

#8: インジェクション

悪意ある攻撃者は、API層を介してシステムに悪意のあるデータを送信し、インジェクション攻撃を行います。データの検証やサニタイズが不十分な場合、APIに影響を及ぼす可能性があります。たとえば、`simple-git`はバージョン3.3.0以下で、引数インジェクションによるコマンドインジェクションの脆弱性があります。Gitのオプションを注入することで、任意のコマンドを実行できました。

 #9: 不適切な資産管理

チームは各APIの目的と構成を把握し、その情報を十分に文書化する必要があります。そうしなければ、必要なときにAPIを更新、修正、廃止できない可能性があります。古いAPIは、最新のAPIよりも攻撃を受けやすくなります。

#10: ログ記録と監視の不足

セキュリティチームが適切なログ記録と監視を実施していないと、攻撃者がチームに気づかれることなく、システムへの侵入を繰り返し試みる可能性があります。

APIセキュリティを強化する2つの方法

OWASP API Top 10のリスクを検討する際、潜在的なセキュリティギャップに対処するために、脆弱性をスキャンすることと、APIのリスクについてチームを教育することの2つに取り組めます。

APIの脆弱性をスキャンする

セキュリティチームは、テクノロジーを使ってバックエンドのAPIコードを評価し、リスクを特定して修正するため、APIの脆弱性を定期的にスキャンする必要があります。既知の脆弱性を持つプロジェクトを使ってスキャン手法を試すことは、こうした取り組みの有効性を確かめるうえで効果的です。こうしたプロジェクトは、OWASPをはじめ、さまざまなリソースから入手できます。

APIの脆弱性をスキャンする方法

Snykは、チームがAPIセキュリティスキャンを実施するのに役立つさまざまなリソースを提供しています。バックエンドのAPIコードをスキャンし、インジェクション、ユーザー認証の不備、過剰なデータ露出などのセキュリティ問題を検出するには、Snyk Codeが役立ちます。Snyk IaCを使えば、コンテナやサーバーレス関数をクラウドにデプロイするためにインフラを構成する際、セキュリティ設定ミス（OWASP APIリスク#7）を検出できます。

OWASP API Top 10の脆弱性についてチームを教育する

チームには、OWASP Top 10について実践に役立つ知識を身につけてもらう必要があります。それぞれの脆弱性が発生する原因を深く理解することで、チームがリスクを生み出す可能性を抑え、修正に積極的に取り組めるようになります。

一般的な脆弱性について学ぶ機会を設けるだけでなく、組織は強固なセキュリティポリシーを策定し、実践的なトレーニングを通じて開発者がそれを実践できるよう支援する必要があります。Snyk Learnでは、APIの脆弱性を含むさまざまなセキュリティトピックについて学べます。セキュリティのベストプラクティスを深く理解すれば、開発者はセキュアコーディング、理解と協力の促進、迅速な修正を通じて、組織全体のセキュリティ態勢の向上に貢献できます。

SnykによるAPIセキュリティ対策

Snykは、組織がより安全なAPIを構築するためのリソースだけでなく、アプリケーションセキュリティとクラウドセキュリティのソリューションも提供しています。さらに、Javaなど、さまざまな言語やフレームワークにおける一般的な脆弱性について、チーム向けの学習リソースを用意しています。

私たちの目標は、俊敏性を損なうことなく、ソフトウェア開発ライフサイクル（SDLC）全体を保護する、開発者に使いやすいシフトレフトのリソースを提供することです。お問い合わせのうえ、ぜひデモをご予約ください。