API Security Checklist

繁中版| 简中版| العرب託| azərbaycan| বাংলা|カタラ| cheština| Deutsch | ελληνικつ| español| فارم|フランセ| हिंदी|インドネシア|イタリアーノ| 日本語| 한국어| ພາສາລາວ| $eдонски| മലയാളം|するまでNederlands |ポルスキー| Português（Brasil）|陶芸| ไทย| Türkçe|あなた好きですtiếngviệt|改善的

APIセキュリティチェックリスト

APIを設計、テスト、リリースする際の最も重要なセキュリティ対策のチェックリスト。

---

認証

• Basic Authを使用しないでください。代わりに標準認証を使用します（例：JWT）。
• Authentication 、 token generation 、 password storageでホイールを再発明しないでください。標準を使用します。
• ログインでMax Retryと刑務所の機能を使用します。
• すべての機密データで暗号化を使用します。

JWT（JSON Webトークン）

• ランダムな複雑なキー（ JWT Secret ）を使用して、トークンを非常に強く強制します。
• ヘッダーからアルゴリズムを抽出しないでください。バックエンド（ HS256またはRS256 ）にアルゴリズムを強制します。
• トークンの有効期限（ TTL 、 RTTL ）を可能な限り短くします。
• JWTペイロードに機密データを保存しないでください。簡単にデコードできます。
• データを保存しすぎないでください。 JWTは通常、ヘッダーで共有され、サイズの制限があります。

アクセス

• DDO /ブルートフォース攻撃を避けるために、リクエスト（スロットリング）を制限します。
• TLS 1.2+を使用してサーバー側でHTTPSを使用して、MITM（中間攻撃の男性）を避けるために暗号を固定します。
• SSLストリップ攻撃を避けるために、SSLを使用してHSTSヘッダーを使用します。
• ディレクトリリストをオフにします。
• プライベートAPIの場合、SAFELISTED IPS/ホストからのみアクセスを許可します。

許可

oauth

• SAFELISTED URLのみを許可するように、 redirect_uriサーバー側を常に検証してください。
• トークンではなくコードと常に交換してみてください（ response_type=token許可しないでください）。
• OAUTH認証プロセスのCSRFを防ぐために、ランダムハッシュを使用してstateパラメーターを使用します。
• デフォルトスコープを定義し、各アプリケーションのスコープパラメーターを検証します。

入力

• 操作に従って適切なHTTPメソッドを使用してください： GET (read) 、 POST (create) 、 PUT/PATCH (replace/update) 、およびDELETE (to delete a record) 、要求されたメソッドがISNの場合は405 Method Not Allowedで応答します要求されたリソースに適しています。
• リクエストに応じてcontent-type検証して、ヘッダー（コンテンツネゴシエーション）を受け入れて、サポートされている形式（ application/xml 、 application/jsonなど）のみを許可し、一致しない場合は406 Not Acceptable応答で応答します。
• 受け入れたように、投稿されたデータのcontent-typeを検証します（例： application/x-www-form-urlencoded 、 multipart/form-data 、 application/jsonなど）。
• 一般的な脆弱性（ XSS 、 SQL-Injection 、 Remote Code Executionなど）を回避するためにユーザー入力を検証します。
• URLで機密データ（ credentials 、 Passwords 、 security tokens 、またはAPI keys ）を使用しないでください。ただし、標準認証ヘッダーを使用します。
• サーバー側の暗号化のみを使用します。
• APIゲートウェイサービスを使用して、キャッシュ、レート制限ポリシー（ Quota 、 Spike Arrest 、またはConcurrent Rate Limit ）を有効にし、APIリソースを動的に展開します。

処理

• 認証プロセスの壊れないように、すべてのエンドポイントが認証の背後に保護されているかどうかを確認してください。
• ユーザー独自のリソースIDは避ける必要があります。 /user/654321/ordersの代わりに/me/orders使用します。
• 自動インクリメントIDをしないでください。代わりにUUID使用してください。
• XMLデータを解析している場合は、 XXE （XML外部エンティティ攻撃）を回避するためにエンティティ解析が有効になっていないことを確認してください。
• XML、YAML、またはアンカーと参照を使用して他の言語を解析している場合は、指数エンティティ拡張攻撃を介してBillion Laughs/XML bomb避けるためにエンティティの拡張が有効になっていないことを確認してください。
• ファイルアップロードにCDNを使用します。
• 膨大な量のデータを扱っている場合は、労働者とキューを使用して、HTTPブロッキングを避けるために、バックグラウンドで可能な限り処理し、応答を迅速に返します。
• デバッグモードをオフにすることを忘れないでください。
• 利用可能な場合は、実行不可能なスタックを使用します。

出力

• X-Content-Type-Options: nosniffヘッダーを送信します。
• X-Frame-Options: deny 。
• Content-Security-Policy: default-src 'none'ヘッダー。
• フィンガープリントヘッダーを削除 - X-Powered-By 、 Server 、 X-AspNet-Versionなど。
• 応答のためのcontent-typeを強制します。 application/jsonを返す場合、 content-type応答はapplication/jsonです。
• credentials 、 passwords 、 security tokensなどの機密データを返さないでください。
• 完了した操作に従って適切なステータスコードを返します。 （例、 200 OK 、 400 Bad Request 、 401 Unauthorized 、 405 Method Not Allowedなど）。

CI＆CD

• ユニット/統合テストのカバレッジで設計と実装を監査します。
• コードレビュープロセスを使用し、自己承認を無視します。
• ベンダーライブラリやその他の依存関係を含む、生産にプッシュする前に、サービスのすべてのコンポーネントがAVソフトウェアによって静的にスキャンされていることを確認してください。
• コードでセキュリティテスト（静的/動的分析）を継続的に実行します。
• 既知の脆弱性については、依存関係（ソフトウェアとOSの両方）を確認してください。
• 展開用のロールバックソリューションを設計します。

監視

• すべてのサービスとコンポーネントに集中ログインを使用します。
• エージェントを使用して、すべてのトラフィック、エラー、リクエスト、および応答を監視します。
• SMS、Slack、電子メール、電報、Kibana、CloudWatchなどのアラートを使用します。
• クレジットカード、パスワード、ピンなどの機密データを記録していないことを確認してください。
• IDSおよび/またはIPSシステムを使用して、APIリクエストとインスタンスを監視します。

---

参照：

• yosriady/api-development-tools-Restful HTTP+JSON APIを構築するための有用なリソースのコレクション。

---

貢献

このリポジトリを分岐し、いくつかの変更を加え、プルリクエストを送信することで、お気軽に貢献してください。どんな質問でも、 [email protected]にメールを送信してください。