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
まで電子メールを送ってください。