English | 繁中版 | 简中版 | Português (Brasil) | Français | 한국어 | Nederlands | Indonesia | ไทย | Русский | Українська | Español | Italiano | Deutsch | Türkçe | Tiếng Việt | Монгол | हिंदी | العربية | Polski | Македонски | ລາວ | فارسی
APIを設計、テスト、リリースするときの最も重要なセキュリティ対策のチェックリスト
-
Basic認証を利用せず、標準的な認証を利用する（例: JWT、OAuth）。 -
認証、トークンの生成、パスワードの保管の車輪の再発明を行わず、標準化されているものを利用する。 - ログインでは
最大リトライ回数（Max Retry）とjail機能を利用する。 - 全ての機密情報は暗号化する。
- ブルートフォース攻撃を困難にするため、ランダムで複雑なキー（
JWT Secret）を使用する。 - ペイロードからアルゴリズムを抽出してはいけない。必ずバックエンドで暗号化する（
HS256またはRS256）。 - トークンの有効期限（
TTL,RTTL）を可能な限り短くする。 - JWTのペイロードに機密情報を格納してはいけない。それは簡単に復号できる。
- サーバサイドで常に
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ヘッダを設定する。
- 操作に応じて適切な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等）。
- ユニットテスト/結合テストのカバレッジで、設計と実装を継続的に検査する。
- コードレビューのプロセスを採用し、自身による承認を無視する。
- プロダクションへプッシュする前に、ベンダのライブラリ、その他の依存関係を含め、サービスの全ての要素をアンチウイルスソフトで静的スキャンする。
- デプロイのロールバックを用意する。
- yosriady/api-development-tools - RESTful HTTP+JSON APIを構築するための有用なリソースの集まり。
このリポジトリをforkして、変更し、プルリクエストを送信し、自由にコントリビューションしてください。何か質問があれば team@shieldfy.io まで電子メールを送ってください。