English | 繁中版 | 简中版 | العربية | Azərbaycan | বাংলা | Català | Čeština | Deutsch | Ελληνικά | Español | فارسی | Français | हिंदी | Indonesia | Italiano | 한국어 | ພາສາລາວ | Македонски | മലയാളം | Монгол | Nederlands | Polski | Português (Brasil) | Русский | ไทย | Türkçe | Українська | Tiếng Việt
APIを設計、テスト、リリースするときの最も重要なセキュリティ対策のチェックリスト
-
Basic認証を利用せず、標準的な認証を利用する（例: JWT、OAuth）。 -
認証、トークンの生成、パスワードの保管において「車輪の再発明」をしないこと。すでに標準化されているものを利用する。 - ログインにおいては
最大リトライ回数（Max Retry）とjail機能を利用する。 - 全ての機微情報において暗号化を活用する。
- ランダムで複雑なキー（
JWT Secret）を使用する。これはブルートフォース攻撃を困難にするため。 - ペイロードからアルゴリズムを抽出しないこと。アルゴリズムは必ずバックエンド処理のみとする（
HS256またはRS256）。 - トークンの有効期限（
TTL,RTTL）を可能な限り短くする。 - JWTのペイロードに機密情報を格納してはいけない。それは簡単に復号できる。
- 多くのデータを保存することを避ける。JWTは通常header「ヘッダー」に共有され、サイズ制限があるため。
- DDoSやブルートフォース攻撃を回避するため、リクエストを制限（スロットリング）する。
- MITM（Man in the Middle Attack）を防ぐため、サーバサイドではHTTPSを使用する。
- SSL Strip attackを防ぐため、SSL化とともに
HSTSヘッダを設定する。 - ディレクトリ・リストをオフにする。
- プライベートAPIの場合、ホワイト・リストに登録されたIP/ホストからのアクセスのみを許可する。
- サーバサイドで常に
redirect_uriを検証し、ホワイトリストに含まれるURLのみを許可する。 - 常にtokenではなくcodeを交換するようにする（
response_type=tokenを許可しない）。 -
stateパラメータをランダムなハッシュと共に利用し、OAuth認証プロセスでのCSRFを防ぐ。 - デフォルトのscopeを定義し、アプリケーション毎にscopeパラメータを検証する。
- 操作に応じて適切な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等）。
- ユニットテスト/結合テストのカバレッジで、設計と実装を継続的に検査する。
- コードレビューのプロセスを採用し、自身による承認を無視する。
- プロダクションへプッシュする前に、ベンダのライブラリ、その他の依存関係を含め、サービスの全ての要素をアンチウイルスソフトで静的スキャンする。
- コードに対してセキュリティ・テスト（静的/動的分析）を継続的に実行する。
- 既知の脆弱性について、依存関係（ソフトウェアとOSの両方）を確認する。
- デプロイのロールバックを用意する。
- すべてのサービスとコンポーネントに集中ログインを使用する。
- すべてのトラフィック、エラー、リクエスト、およびレスポンスを監視ために、エージェントを使用する。
- SMS、Slack、Email、Telegram、Kibana、Cloudwatch、などのアラートを使用する。
- クレジット・カード、パスワード、ＰＩＮ、などの機密データをログに記録していないことを確認する。
- ＡＰＩリクエストとインスタンスを監視ためにＩＤＳやＩＰＳシステムを使用する。
- yosriady/api-development-tools - RESTful HTTP+JSON APIを構築するための有用なリソースの集まり。
このリポジトリをforkして、変更し、プルリクエストを送信し、自由にコントリビューションしてください。何か質問があれば team@shieldfy.io まで電子メールを送ってください。