このサイトを正しく表示するには、最新のブラウザを使用し、Javascriptを有効化してください。

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

justin2018

認証

[ ] Basic認証を利用せず、標準的な認証を利用する（例: JWT、OAuth）。
[ ] 認証、トークンの生成、パスワードの保管において「車輪の再発明」をしないこと。すでに標準化されているものを利用する。
[ ] ログインにおいては最大リトライ回数（Max Retry）とjail機能を利用する。
[ ] 全ての機微情報において暗号化を活用する。

JWT (JSON Web Token)

[ ] ランダムで複雑なキー（JWT Secret）を使用する。これはブルートフォース攻撃を困難にするため。
[ ] ペイロードからアルゴリズムを抽出しないこと。アルゴリズムは必ずバックエンド処理のみとする（HS256またはRS256）。
[ ] トークンの有効期限（TTL, RTTL）を可能な限り短くする。
[ ] JWTのペイロードに機密情報を格納してはいけない。それは簡単に復号できる。
[ ] あまり多くのデータを保存するに避けるください。JWTは通常header「ヘッダー」に共有され、サイズ制限があります。

OAuth

[ ] サーバサイドで常にredirect_uriを検証し、ホワイトリストに含まれるURLのみを許可する。
[ ] 常にtokenではなくcodeを交換するようにする（response_type=tokenを許可しない）。
[ ] stateパラメータをランダムなハッシュと共に利用し、OAuth認証プロセスでのCSRFを防ぐ。
[ ] デフォルトのscopeを定義し、アプリケーション毎にscopeパラメータを検証する。

アクセス

[ ] DDoSやブルートフォース攻撃を回避するため、リクエストを制限（スロットリング）する。
[ ] MITM（Man in the Middle Attack）を防ぐため、サーバサイドではHTTPSを使用する。
[ ] SSL Strip attackを防ぐため、SSL化とともにHSTSヘッダを設定する。
[ ] ディレクトリ・リストをオフにしてください。
[ ] プライベートAPIの場合、ホワイト・リストに登録されたIP/ホストからのアクセスのみを許可します。

入力

[ ] 操作に応じて適切なHTTPメソッドを利用する。GET（読み込み）, POST（作成）, PUT/PATCH（置き換え/更新）, DELETE（単一レコードの削除）。リクエストメソッドがリソースに対して適切ではない場合、405 Method Not Allowedを返す。
[ ] リクエストのAcceptヘッダ（コンテンツネゴシエーション）のcontent-typeを検証する。サポートしているフォーマット（例: application/xml, application/json等）は許可し、そうでない場合は406 Not Acceptableを返す。
[ ] POSTされたデータのcontent-typeが受け入れ可能（例: application/x-www-form-urlencoded, multipart/form-data, application/json等）かどうかを検証する。
[ ] ユーザーの入力に一般的な脆弱性が含まれていないことを検証する（例: XSS, SQLインジェクション, リモートコード実行等）。
[ ] URLの中に機密情報（認証情報, パスワード, セキュリティトークン）を利用せず、標準的な認証ヘッダを使用する。
[ ] サーバー側の暗号化のみを使用してください。
[ ] キャッシュ、Rate Limit policies（例: Quota, Spike Arrest, Concurrent Rate Limit）を有効化し、APIリソースのデプロイを動的に行うため、APIゲートウェイサービスを利用する。

処理

[ ] 壊れた認証プロセスを回避するため、全てのエンドポイントが認証により守られていることを確かめる。
[ ] ユーザーに紐付いたリソースIDを使用してはならない。/user/654321/ordersの代わりに/me/ordersを利用する。
[ ] オートインクリメントなIDを利用せず、代わりにUUIDを利用する。
[ ] XMLファイルをパースする場合、XXE（XML external entity attack）を回避するため、entity parsingが有効でないことを確認する。
[ ] XMLファイルをパースする場合、exponential entity expansion attackによるBillion Laughs/XML bomb攻撃を回避するためentity expansion が有効でないことを確認する。
[ ] ファイルアップロードにはCDNを利用する。
[ ] 大量のデータを扱う場合、バックグラウンドでWorkerプロセスやキューを出来る限り使用し、レスポンスを速く返すことで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にする。
[ ] 認証情報, パスワード, セキュリティトークンといった機密情報を返さない。
[ ] 処理の終了時に適切なステータスコードを返す（例: 200 OK, 400 Bad Request, 401 Unauthorized, 405 Method Not Allowed等）。

CI & CD (継続的インテグレーションと継続的デリバリー)

[ ] ユニットテスト/結合テストのカバレッジで、設計と実装を継続的に検査する。
[ ] コードレビューのプロセスを採用し、自身による承認を無視する。
[ ] プロダクションへプッシュする前に、ベンダのライブラリ、その他の依存関係を含め、サービスの全ての要素をアンチウイルスソフトで静的スキャンする。
[ ] コードに対してセキュリティ・テスト（静的/動的分析）を継続的に実行して。
[ ] 既知の脆弱性について、依存関係（ソフトウェアとOSの両方）を確認して。
[ ] デプロイのロールバックを用意する。

参照：

yosriady/api-development-tools - RESTful HTTP+JSON APIを構築するための有用なリソースの集まり。

コントリビューション

justin2018 · 2022-10-29T11:20:57+00:00

認証 [ ] Basic認証を利用せず、標準的な認証を利用する（例: JWT、OAuth）。 [ ] 認証、トークンの生成、パスワードの保管において「車輪の再発明」をしないこと。すでに標準化されているものを利用する。 [ ] ログインにおいては最大リトライ回数（Max Retry）とjail機能を利用する。...

このリポジトリをforkして、変更し、プルリクエストを送信し、自由にコントリビューションしてください。何か質問があれば team@shieldfy.io まで電子メールを送ってください。