認証とは、ユーザー、システム、またはプロセスの身元を確認するプロセスです。APIの文脈においては、OAuth 2.0やAPIキー、JWT仕様といったユーザー認証プロトコルを使用して、リクエストを行う者が本人であることを証明することを指します。

対照的に、承認とは認証されたユーザーが何にアクセスできるかを照合するプロセスです。ユーザーを認証した後は、ユーザーが必要または要求するリソースへのアクセスを、役割に則ったアクセス制御により厳密に制限しなければなりません。

暗号化により、プレーン・テキストやその他の種類のデータが、読み取り可能な形式から、復号化キーを持つエンティティーのみが復号できるエンコードされた形式に変換されます。トランスポート層セキュリティー（TLS）、SSL接続、TLS暗号化プロトコルなどの暗号化テクノロジーを使用することで、APIトラフィックが悪意のあるユーザーや権限のないユーザーによって傍受または変更されないようにすることができます。

入力検証プロトコルは、入力が処理される前に特定の基準（長さ、タイプ、形式、範囲など）を満たしていることを確認することで、SQLインジェクション攻撃やクロスサイト・スクリプティングなどの悪意のあるデータからAPIを保護します。Webアプリケーション・ファイアウォール（WAF）とXMLまたはJSONスキーマ検証を利用することで、セキュリティーチームが検証プロセスを自動化し、受信リクエストを先手を取って分析し、悪意のあるトラフィックがサーバーに到達する前にブロックするのに役立ちます。

レート制限は、特定の時間内でユーザーまたはIPアドレスが実行できるコール回数を制限します。これにより、ブルート・フォース攻撃やDoS攻撃からAPIリソースを保護できる仕組みです。レート制限により、すべてのAPIリクエストが迅速に処理され、ユーザーがシステムに有害なリクエストを大量に送り込むことがなくなります。

レート制限と同様に、スロットリングはシステムが受信するAPI呼び出しの数を制限します。ただし、スロットルはユーザー/クライアント・レベルで動作するのではなく、サーバー/ネットワーク・レベルで動作します。スロットル制限とクォータは、APIの呼び出し、メッセージ、またはその両方を1秒あたりの特定の数に制限することで、APIバックエンド・システムの帯域幅を確保します。

セキュリティー・ヘッダーは、クリック・ジャッキング攻撃の防止に特に効果的です。たとえば、「content-security-policy」ヘッダーは、サーバーからどのリソースを要求できるかをブラウザーに伝えます。「x-content-type-option」ヘッダーはブラウザがコンテンツ・タイプをMIMEスニッフィングしようとするのを阻止し、「strict-transport-security」ヘッダーはサーバーへの安全な（HTTP over SSL/TLS）接続を強制します。

APIゲートウェイのインストールは、特にオープンAPIの場合、APIアクセスを制限し、ネットワーク・セキュリティーの層を追加する最も簡単な方法の1つです。APIゲートウェイは、システムが受信するすべてのAPIリクエストの単一のエントリー・ポイントとして機能し、APIインタラクションを標準化し、キャッシュ、分析、APIコンポジション、レート制限、暗号化、ロギング、アクセス制御などのセキュリティ機能を提供します。

包括的な最新の監査ログを保持し、頻繁に確認することで、組織はデータ・アクセスと使用状況を追跡し、すべてのAPIリクエストを記録できます。APIエコシステムの複雑さを考慮すると、APIのアクティビティーを常に把握し続けるのは、非常に労力がかかる場合がありますが、データ侵害やコンプライアンスの違反後にチームが手順を再追跡する必要がある場合は、監査とログの手順を実行することで時間を節約できます。

API環境でのプロアクティブなエラー処理により、サイバー犯罪者がAPIプロセスに関する機密情報を漏らすことを防ぐことができます。理想的には、APIエラーは、エラーの性質を大まかに示すHTTPステータス・コードを返し、過剰なデータ漏洩の危険を冒さずにチームが問題を理解し、対処するための十分なコンテキストを提供します。

他のソフトウェア・アプリケーションやシステムと同様に、APIセキュリティーを維持するには、注意深くリアルタイムの監視と保守を行うことが不可欠です。異常なネットワーク・アクティビティーに常に注意し、最新のセキュリティー・パッチ、バグ修正、新機能でAPIを更新してください。

組織は、Open Web Application Security Project（OWASP）のAPIセキュリティー推奨事項のような、タイムリーなセキュリティ標準を採用する必要もあります。たとえば、OWASP API Security Top 10リストは、認証の失敗、一括割り当て、サーバー側のリクエスト・フォージェリなど、最も重要かつ一般的な APIセキュリティーの脅威を理解し、軽減するためのフレームワークを提供します。

APIソフトウェアのすべての新しいバージョンには、以前のバージョンのセキュリティー・ギャップを補うセキュリティー・アップデートとバグ修正が付属しています。しかし、適切なバージョン管理を実践しないと、ユーザーが誤って（または意図的に）APIの古いバージョンをデプロイし、機密データが危険にさらされる可能性があります。注意深いバージョニングとドキュメント化の実践により、企業はサービスを中断することなくAPI開発を加速し、古い APIバージョンを段階的に廃止し、ユーザーをより新しく、セキュアなイテレーションに誘導することができます。

たとえば、チームがAPIのv1でセキュリティー上の欠陥を発見した場合は、v2で修正できます。また、バージョン管理により、セキュリティーチームは、v1に既知のセキュリティー脆弱性があることをバージョンのドキュメントで明確にしながら、ユーザー自身のペースでv1からv2に移行することを奨励できます。

セキュリティー・テストでは、開発者はAPIクライアントを使用して標準リクエストを送信し、システム応答の品質と正確さを評価する必要があります。定期的なセキュリティー・テストを実施してセキュリティー・ギャップを特定・対処することで、チームは攻撃者が悪用する前にAPIの脆弱性を修正できます。