English | 中文版 | Português (Brasil) | Français | 한국어 | Nederlands | Indonesia | ไทย | Русский | Українська | Español | Italiano | Deutsch | Türkçe | Tiếng Việt | Монгол
これはAPIの設計, テスト, リリース時における、重要なセキュリティ対策チェックリストです。
-
Basic認証を使用してはならない。標準的な認証を使う。(例 JWT, OAuth) -
認証,トークン生成,パスワードの保管において車輪の再発明をしてはならない。 -
最大ログイン試行回数(Max Retry) と、jail featuresを使用する。 - 全ての秘匿情報を暗号化する。
- ブルートフォース攻撃を困難にするため、ランダムで複雑なキー (
JWT Secret) を使用する。 - ペイロードからアルゴリズムを抽出してはならない。必ずバックエンドで暗号化する。(
HS256若しくはRS256) - トークンの有効期限 (
TTL,RTTL) は、可能な限り短くする。 - JWTのペイロードに秘匿情報を含めてはならない。それは簡単に復号化される。
- サーバサイドで常に
redirect_uriを検証し、ホワイトリストに含まれるURLのみを許可する。 - tokenではなく、codeでのやり取りを心がける。(
response_type=tokenを許可しない) - OAuthの認証プロセスでのCSRFを防ぐため、
stateパラメータはランダムなハッシュと合わせて使用する。 - デフォルトのscopeを指定し、各アプリケーションでscopeパラメータを検証する。
- DDoSやブルートフォース攻撃を避けるため、リクエストの制限 (スロットリング) を設ける。
- MITM (Man In The Middle Attack) を防ぐため、サーバサイドではHTTPSを使用する。
- SSL Strip attackを防ぐため、SSL化して
HSTSを設定する。
- 処理内容に応じて、適切なHTTPメソッドを使用する。:
GET (read),POST (create),PUT/PATCH (replace/update),DELETE (レコード削除)。リクエストメソッドがリソースに対して適切ではない場合、405 Method Not Allowedを返す。 - HTTPヘッダーのAccept (コンテンツネゴシエーション) の
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等) - 秘匿情報 (
クレデンシャル情報,パスワード,セキュリティトークン,APIキー) をURLに使用してはならない。標準のAuthorizationヘッダを使用する。 - APIゲートウェイを使用し、キャッシュ, Rate Limit policies (例
Quota,Spike Arrest,Concurrent Rate Limit), 動的なAPIリソースのデプロイを有効化する。
- 壊れた認証プロセスを避けるため、全てのエンドポイントが認証により守られていることを確かめる。
- ユーザーに紐付いたリソースIDを使用してはならない。
/user/654321/ordersではなく/me/ordersを使用する。 - auto-incrementなIDではなく、
UUIDを使用する。 - XMLファイルをパースする時、エンティティのパースが有効ではないことを確認する。
XXE攻撃(XML external entity attack) を避けるため。 - XMLファイルをパースする時、エンティティ参照が有効ではないことを確認する。指数関数的エンティティ展開 (exponential entity expansion) による
Billion Laughs/XML bombを避けるため。 - ファイルのアップロードにはCDNを使用する。
- 大量のデータを扱う場合、バックグラウンドでWorkerプロセスやキューを出来る限り沢山使用し、返答を速く返すことでHTTPブロッキングを避ける。
- デバッグモードをOFFにすることを忘れてはならない。
-
X-Content-Type-Options: nosniffをヘッダに付与する。 -
Send X-Frame-Options: denyをヘッダに付与する。 -
Content-Security-Policy: default-src 'none'をヘッダに付与する。 - fingerpringing headersを削除する。 -
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等)
- ユニットテスト/結合テストのカバレッジで、設計と実装を継続的に検査する。
- コードレビュープロセスを導入し、自画自賛を止める。
- productionにpushする前に、そのサービスの全てのコンポーネントをアンチウイルスソフトで静的スキャンする。ベンダーのライブラリやその他の依存するものも含めて。
- デプロイのロールバックを用意する。
お気軽にこのリポジトリをフォークし、変更を加え、プルリクエストを送って下さい。ご質問はこちらのメールアドレスまでお願い致します。team@shieldfy.io