APIセキュリティ

よくあるAPIセキュリティの脅威と脆弱性にはどのようなものがありますか？

APIは現代のビジネスに欠かせない存在であり、その重要性の高まりとともに主要な攻撃対象となっています。Open Web Application Security Project（OWASP）は、Webアプリケーションに対する一般的なセキュリティ脅威のトップ10リストを公開していますが、APIに対する脅威の増加を受けて、OWASPはAPI固有の重大なセキュリティリスクを追跡するための専用プロジェクトも立ち上げています。これら2つのリストでは幅広い脆弱性が取り上げられており、大きく次のカテゴリーに分類できます。

セキュリティ衛生管理が不十分

これは最も基本的なセキュリティ脆弱性のカテゴリーですが、同時に最も重要なものの1つでもあります。適切なセキュリティ対策を維持できていない場合、本来であれば容易に防げたはずの重大なセキュリティ侵害につながる可能性があります。たとえば、トークンやAPIキーをハードコードしたり、APIクライアントライブラリのソースコード、Gitの履歴、ドキュメントに含めたりしないよう徹底する必要があります。また、APIがHTTPベースのREST APIであっても、Protocol BuffersベースのgRPC APIであっても、すべてのAPI通信を暗号化するためにTLS（Transport Layer Security）を利用する必要があります。

認証および認可の脆弱性

APIでは、ユーザーの役割に応じて異なる権限が付与されることが一般的です。そのため、認証や認可に関する問題は、本来制限されるべき操作の実行やデータへのアクセスを可能にしてしまうため、重大なセキュリティリスクとなります。

こうした問題がAPIに入り込む経路は数多くあります。たとえば、組織がメソッドレベルの認可チェックを適切に実施せず、読み取りや書き込みの対象となるオブジェクトがユーザーの認可範囲内にあることを確認できていない場合があります。また、認可がAPIエンドポイント単位で管理されている一方で、個々のオブジェクトにさらに細かな権限設定が存在する場合、不適切な権限チェックによって不正アクセスが発生する可能性があります（これは次に説明する「読み取り・書き込み権限の粒度不足」に関連する脆弱性です）。さらに、ユーザー認証のワークフローで公開鍵暗号方式などの暗号技術を利用していない場合、なりすまし攻撃のリスクが高まります。

読み取り・書き込み権限の粒度不足

データオブジェクトには多くのプロパティがあり、その中には機密性の高いものもあれば、そうでないものもあります。たとえば、Userオブジェクトには機密性の低いusernameプロパティと、機密性の高い passwordプロパティが含まれる場合があります。開発者がサーバー側で機密プロパティを適切に保護せず、クライアント側で除外することを前提にしてしまうケースがありますが、この場合、悪意のある第三者からアクセスできる状態になってしまいます。この脆弱性は「過剰なデータ露出（Excessive Data Exposure）」と呼ばれます。

同様に、ユーザーはuser.idのような内部プロパティや、user.is_adminのような権限に関するプロパティを更新できるべきではありません。しかし、APIがクライアントから受け取ったすべてのデータを一括で割り当てるよう実装されていると、「マスアサインメント（Mass Assignment）」の脆弱性が発生することがあります。これを防ぐためには、各プロパティを個別に検証し、そのユーザーが更新を許可されているプロパティにのみ新しい値を割り当てるロジックを実装する必要があります。

クォータとスロットリングの未実装

クォータとスロットリングは、計算リソースを保護し、高い可用性を維持するために、特定のサービスに対するリクエスト数を制限する仕組みです。クォータやスロットリングを実装していないAPIは、攻撃者がパスワードを総当たりで推測して不正アクセスを試みるブルートフォース攻撃や、大量のトラフィックを送り込んで下流サービスのリソースを枯渇させ、サービスを停止に追い込むDoS（Denial of Service）攻撃に対して脆弱になる可能性があります。

不適切に設定された、または欠落しているHTTPヘッダー

WebクライアントがAPIに最初のリクエストを送信する際、レスポンスにはセキュリティヘッダーを含む適切なHTTPヘッダーが設定されている必要があります。セキュリティヘッダーは、ブラウザーがAPIと安全にやり取りするための指示を提供します。たとえば、HTTP Strict Transport Security（HSTS）ヘッダーを使用することで、有効な証明書とTLS通信を強制できます。また、Access-ControlヘッダーやCross-Origin Resource Policy（CORP）ヘッダーは、正規のクライアントが悪意のある第三者によって悪用され、その代理としてAPIリクエストを実行されることを防ぐのに役立ちます。

さらに、Cache-ControlヘッダーやVaryヘッダーなどが不適切に設定されている場合、Webサーバーの前段にプロキシやロードバランサーが配置されている環境では、機密データが他のAPIクライアントに漏えいする可能性があります。

メソッドレベルでの入力検証、サニタイズ、エンコードの未実施

APIインジェクションは、攻撃者がAPIを通じて悪意のあるコードを送信することで発生します。このコードは、多くの場合リクエストのパラメーターやリクエストボディに含まれています。悪意のあるコードは、サーバー側で実行される場合があります（たとえば、SQLクエリやデータのデシリアライズ処理時など）。また、HTMLコンテンツに埋め込まれたコードが事前に適切にエスケープされていない場合、クライアント側で実行されることもあります。こうしたコードが実行されると、本来保護されるべき権限設定やデータベースレコードが改ざんされたり、任意のリモートコード実行（RCE）につながったりする可能性があります。そのため、開発者はWeb Application Firewall（WAF）を活用するとともに、メソッドレベルで入力検証、サニタイズ、エンコードを実施し、不正または安全でないデータがワークフローに入り込まないようにすることが重要です。OWASPのESAPIのようなライブラリを利用することで、この種の脆弱性の発生を抑えることができます。

不正確な資産管理とドキュメント

チームは通常、エンドポイント、バージョン、サードパーティサービスなど、多数のAPIアセットの管理を担っています。しかし、こうしたアセットが増えるにつれて、それらを適切に文書化し、安全に管理することはますます難しくなります。たとえば、古いAPIバージョンの廃止を忘れてしまうと、後から修正された脆弱性を攻撃者に悪用される可能性があります。この問題は「不適切な資産管理（Improper Assets Management）」と呼ばれます。また、すべてのAPIアセットとそれぞれがシステム全体で果たす役割を正確に記載した最新のドキュメントを維持できていない場合、そのリスクはさらに高まります。

不十分なログ記録と監視

ログにはシステム上で発生したすべてのアクティビティの詳細が記録されるため、APIを含む環境内のあらゆるサービスやインフラストラクチャコンポーネントでログ記録を有効にすることが重要です。しかし、小規模なシステムであっても1日に数百万件のログが生成されることがあり、不審なアクティビティを迅速に特定することは容易ではありません。また、ログには機密データが含まれる場合もあるため、セキュリティとコンプライアンスを確保するために適切に取り扱う必要があります。そのためチームは、ログ記録だけでなく堅牢な監視戦略も導入し、ログストリーム内のセキュリティ侵害や機密データを迅速に検出できるようにする必要があります。

他のAPIアーキテクチャでは、どのようなAPIセキュリティの脆弱性に注意すべきでしょうか？

RESTは依然として最も広く利用されているAPIアーキテクチャですが、特定のユースケースに対応するためにSOAP、GraphQL、WebSockets、gRPCを採用する開発者もいます。それぞれのアーキテクチャには固有のセキュリティ上の考慮事項があり、ここではその主なポイントを紹介します。

• SOAP：SOAP（Simple Object Access Protocol）はXMLベースのメッセージングプロトコルです。しかし、XML処理モジュールは悪意を持って作成されたデータに対して十分に安全でない場合があるため、APIとその下流サービスを保護するには常に最新のライブラリを利用することが重要です。また、SOAP APIではリモートプロシージャコール（RPC）でシリアライズ処理が使用されることがあり、攻撃者がリクエスト内に悪意のあるコードを隠す余地を生む可能性があります。
• GraphQL：GraphQLは、単一のAPIエンドポイントを通じて複数のデータソースに接続し、やり取りできるクエリ言語です。GraphQLは複数のデータソースを横断して利用するため、一見単純なリクエストでも下流で大規模な処理が必要になったり、アクセス権限を超える広範な読み取り・書き込み操作につながったりする可能性があります。そのため、GraphQLベースのアーキテクチャでは、クォータやスロットリング、そして権限設定の粒度が特に重要になります。
• WebSocket： WebSocketは、単一のTCP接続上でクライアントとサーバー間の継続的な双方向通信を可能にします。WebSocket自体は認証や暗号化を直接提供しないため、開発者はTLSの利用や認可チェックを明示的に実装する必要があります。また、WebSocketには同一オリジンポリシーが適用されないため、OWASPが2013年に追跡していたCross-Site Request Forgery（CSRF）の派生形として、「Cross-Site WebSocket Hijacking」が問題視されています。さらに、WebSocketベースのアプリケーションも一般的なWebアプリケーションやAPIの脆弱性の影響を受けるため、レート制限やCSRF対策、入出力の検証とサニタイズ、Originヘッダーの許可リスト検証などのセキュリティ対策を適用する必要があります。
• gRPC：gRPCはHTTP/2上で動作するリモートプロシージャコール（RPC）フレームワークであり、多様な言語で構築されたサービスやクライアント間の低レイテンシな通信を大規模に実現します。SOAPと同様に、gRPCもデータ伝送にシリアライズを利用しますが、その仕組みとしてProtocol Buffersを採用しています。Googleの標準的なProtocol Buffersライブラリを利用することで安全でないデシリアライズを回避できますが、非標準の実装には独自のセキュリティ上の考慮事項が存在する可能性があるため、慎重に利用する必要があります。

APIセキュリティにPostmanを選ぶ理由

Postmanは、設計から運用まで、API、データ、ワークフローを保護するための統合型エンタープライズプラットフォームを提供します。

• BYOK暗号化で機密データを保護：Postmanは、エンタープライズのお客様向けにBYOK暗号化（Bring Your Own Key）をサポートしています。これにより、環境、グローバル変数、履歴などのAPI関連データがクラウド上でどのように暗号化されるかを、お客様自身で管理できます。Postmanは、お客様のAWS KMSアカウントに保存された組織独自の鍵を使用してデータを暗号化するため、お客様の許可なく、Postmanを含む誰もそのデータにアクセスできません。
• API定義とリクエストにAPIセキュリティルールを適用：Postman APIセキュリティには、OWASP API Security Top 10に基づくデフォルトのセキュリティルールセットが用意されています。これにより、API環境全体に存在する一般的な脆弱性やルール違反を自動的に検出できます。
• 組織の要件に合わせてセキュリティルールをカスタマイズ：組織ごとに要件は異なります。そのため、Postman APIセキュリティでは、Spectralガイドラインに基づいてカスタムルールを定義・インポートできます。
• CI/CDパイプラインにAPIセキュリティチェックを統合：セキュリティ問題はできるだけ早い段階で発見することが重要です。Postman APIセキュリティルールは、CI/CDのビルドステージでAPI定義に対して自動実行できます。パイプライン内で違反が検出された場合は、ビルドを停止してデプロイを防ぐことが可能です。
• APIのパフォーマンスとレスポンス時間を監視：APIセキュリティはAPIパフォーマンスに直接影響する場合があります。Postmanモニターを利用することで、APIのパフォーマンスやレスポンス時間を継続的に可視化し、問題を迅速に検出できます。
• セキュリティテストを自動化してリグレッションを防止：Postmanでは、テストスクリプトを作成してセキュリティテストを自動化できます。たとえば、認可テストはPostmanのスクリプト機能を使って簡単に自動化できます。また、モニターを設定することで、テスト結果を継続的に監視し、リグレッションを防止できます。
• バージョン管理を実装：Postmanのコラボレーション機能にはバージョン管理が含まれており、チームはAPIのバージョン履歴を追跡しながら、最新バージョンの安全性を維持できます。
• ドキュメントを常に最新の状態に維持：Postmanは、あらゆるコレクションやOpenAPI 3.0定義に対してドキュメントを自動生成します。変更内容はドキュメントに自動的に反映されるため、チームは管理対象のAPIアセットについて常に正確かつ包括的に把握できます。