OWASPアプリケーションセキュリティ検証標準レポート

アプリケーションセキュリティ検証標準（ASVS）は、アーキテクト、開発者、テスター、セキュリティ専門家、ツールベンダー、消費者が、セキュアなアプリケーションを定義し、構築し、テストし、検証するために使用できるアプリケーションセキュリティ要件またはテストのリストです。

アプリケーションセキュリティ検証標準（ASVS）の目標

  • 組織が安全なアプリケーションを開発し、維持するのを支援するために。
  • セキュリティサービスのベンダー、セキュリティツールのベンダー、および消費者が自分たちの要件と提供物を調整できるようにする。

AppScan と ASVS 標準

この AppScan コンプライアンスレポートはASVSレベル3を使用しています。ASVSレベル3は、最も重要なアプリケーション、つまり、高額取引を行うアプリケーション、機密性の高い医療データを含むアプリケーション、または最高レベルの信頼性が必要なアプリケーションのためのものです。

アプリケーションセキュリティ検証標準は、OWASPによって開発および維持されています。この規格は、クリエイティブ・コモンズ 表示 - 継承 3.0 ライセンスの下でリリースされています。詳細については、OWASPアプリケーションセキュリティ検証標準 V4.0.3をご覧ください。

ウェブアプリケーションのセキュリティに関する詳細は、HCL AppScan: 高度なアプリケーションセキュリティテストをご覧ください。

規制のセクション

ID 名前
1.2.1 すべてのアプリケーションコンポーネント、サービス、およびサーバーに対して、ユニークまたは特別な低権限オペレーティングシステムアカウントの使用を確認してください。
1.2.2 アプリケーションコンポーネント間の通信、API、ミドルウェア、データレイヤーを含む、が認証されていることを確認してください。コンポーネントは、必要最小限の権限を持つべきです。
1.2.3 アプリケーションが、安全性が確認されている単一の検証済み認証メカニズムを使用し、強力な認証を含めることができ、アカウントの乱用や侵害を検出するための十分なログと監視があることを確認してください。
1.2.4 すべての認証パスウェイとアイデンティティ管理APIが、アプリケーションのリスクに応じてより弱い代替手段がないように、一貫した認証セキュリティ制御強度を実装していることを確認してください。
1.4.4 アプリケーションが保護されたデータとリソースにアクセスするための単一でよく審査されたアクセス制御メカニズムを使用していることを確認してください。すべてのリクエストは、コピー＆ペーストや安全でない代替経路を避けるために、この単一のメカニズムを通過しなければなりません。
1.4.5 属性または機能ベースのアクセス制御が使用されていることを確認してください。コードはユーザーの役割だけでなく、機能/データ項目に対するユーザーの認証をチェックします。権限はまだ役割を使用して割り当てるべきです。
1.5.2 信頼できないクライアントと通信する際にシリアライゼーションが使用されていないことを確認してください。これが不可能な場合は、適切な完全性制御（および機密データが送信される場合は暗号化）が強制され、オブジェクトインジェクションを含むデシリアライゼーション攻撃を防ぐことを確認してください。
1.5.3 信頼できるサービスレイヤーで入力検証が強制されていることを確認してください。
1.5.4 出力エンコーディングが、それが意図されたインタープリタの近くまたはそれによって行われることを確認してください。
1.6.2 暗号化サービスの消費者が、キーボールトまたはAPIベースの代替手段を使用してキーマテリアルや他の秘密を保護していることを確認してください。
1.6.3 すべてのキーとパスワードが交換可能であり、機密データを再暗号化するための明確に定義されたプロセスの一部であることを確認してください。
1.6.4 アーキテクチャがクライアント側の秘密--対称キー、パスワード、またはAPIトークンなど--を不安全として扱い、それらを使用して機密データを保護またはアクセスしないことを確認してください。
1.9.1 アプリケーションがコンポーネント間の通信を暗号化していることを確認してください、特にこれらのコンポーネントが異なるコンテナ、システム、サイト、またはクラウドプロバイダーにある場合には特にです。
1.9.2 アプリケーションコンポーネントが通信リンクの各側の真正性を確認し、パーソン・イン・ザ・ミドル攻撃を防ぐことを確認してください。たとえば、アプリケーションコンポーネントはTLS証明書とチェーンを検証するべきです。
1.11.2 すべての高価値ビジネスロジックフロー、認証、セッション管理、アクセス制御を含む、が非同期状態を共有していないことを確認してください。
1.11.3 すべての高価値ビジネスロジックフロー、認証、セッション管理、アクセス制御がスレッドセーフであり、チェック時と使用時のレースコンディションに対して耐性があることを確認してください。
1.14.6 アプリケーションが、NSAPIプラグイン、Flash、Shockwave、ActiveX、Silverlight、NACL、またはクライアントサイドのJavaアプレットなど、サポートされていない、安全でない、または廃止されたクライアントサイドの技術を使用していないことを確認してください。
2.1.1 ユーザーが設定したパスワードが少なくとも12文字以上であることを確認してください（複数のスペースが結合された後）。
2.1.2 少なくとも64文字以上のパスワードが許可されていること、そして128文字以上のパスワードが拒否されていることを確認してください。
2.2.1 侵害された資格情報のテスト、ブルートフォース、アカウントロックアウト攻撃を軽減するために、反自動化コントロールが効果的であることを確認してください。そのようなコントロールには、最も一般的に侵害されるパスワードのブロック、ソフトロックアウト、レート制限、CAPTCHA、試行間の遅延時間の増加、IPアドレスの制限、または場所、デバイスでの初回ログイン、アカウントの解除を試みる最近の試みなどのリスクベースの制限が含まれます。単一のアカウントで1時間に100回以上の失敗試行が可能でないことを確認してください。
2.2.2 弱い認証手段（SMSやメールなど）の使用が、二次確認や取引承認に限定され、より安全な認証方法の代替手段としては使用されていないことを確認してください。強力な方法が弱い方法よりも先に提供されていること、ユーザーがリスクを認識していること、またはアカウントの危険性を制限するための適切な対策が講じられていることを確認してください。
2.2.4 フィッシングに対するなりすまし耐性を確認します。たとえば、マルチファクター認証、意図を持つ暗号化デバイスの使用（認証のためのプッシュを持つ接続キーなど）、または高いAALレベルでは、クライアント側の証明書などです。
2.2.5 資格情報サービスプロバイダー（CSP）と認証を検証するアプリケーションが分離されている場合、両エンドポイント間に相互認証TLSが配置されていることを確認してください。
2.2.6 ワンタイムパスワード（OTP）デバイス、暗号化認証器、またはルックアップコードの義務的な使用を通じて、リプレイ抵抗を確認してください。
2.3.1 システムが生成する初期パスワードやアクティベーションコードは、安全にランダムに生成されるべきであり、少なくとも6文字以上であるべきであり、文字と数字を含むことができ、短期間後に期限切れになることがあります。これらの初期の秘密は、長期間のパスワードになってはならない。
2.4.1 パスワードがオフライン攻撃に耐性のある形式で保存されていることを確認してください。パスワードは、承認された一方向キー導出またはパスワードハッシュ関数を使用して、ソルト化およびハッシュ化する必要があります。キーデリベーションとパスワードハッシュ関数は、パスワードハッシュを生成する際に、パスワード、ソルト、コストファクターを入力として受け取ります。
2.4.2 塩が少なくとも32ビットの長さであり、保存されたハッシュ間の塩値の衝突を最小限に抑えるために任意に選ばれていることを確認してください。各資格情報に対して、ユニークなソルト値と結果として得られるハッシュは保存されなければなりません。
2.4.3 PBKDF2が使用されている場合、イテレーション回数は検証サーバーのパフォーマンスが許す限り大きくするべきで、通常は少なくとも100,000回のイテレーションが必要であることを確認してください。
2.4.4 bcryptが使用されている場合、検証サーバーのパフォーマンスが許す限り、ワークファクターは可能な限り大きくするべきであり、最低でも10であることを確認してください。
2.4.5 キー導出関数の追加の反復が行われていることを確認してください。これは、秘密のソルト値を使用しており、検証者のみが知っています。承認されたランダムビットジェネレーター[SP 800-90Ar1]を使用してソルト値を生成し、最新版のSP 800-131Aで指定された最小のセキュリティ強度を少なくとも提供してください。秘密の塩値は、ハッシュ化されたパスワードとは別に保存する必要があります（例えば、ハードウェアセキュリティモジュールのような専用デバイスに）。
2.5.1 システムが生成した初期アクティベーションまたはリカバリーシークレットが、ユーザーに対して平文で送信されていないことを確認してください。
2.5.2 パスワードのヒントや知識ベースの認証（いわゆる秘密の質問）が存在しないことを確認してください。
2.5.3 パスワード資格情報の回復が、現在のパスワードを何らかの形で明らかにしないことを確認してください。
2.5.4 共有またはデフォルトのアカウントが存在しないことを確認してください（例：root、admin、またはsa）。
2.6.1 ルックアップシークレットが一度だけ使用できることを確認してください。
2.6.2 ルックアップシークレットが十分なランダム性（エントロピー112ビット）を持っていることを確認するか、エントロピーが112ビット未満の場合は、ユニークでランダムな32ビットのソルトで塩漬けにし、承認された一方向ハッシュでハッシュ化します。
2.6.3 ルックアップシークレットが予測可能な値などのオフライン攻撃に対して耐性があることを確認してください。
2.10.1 サービス内の秘密が、パスワード、APIキー、特権アクセスを持つ共有アカウントなどの変わらない資格情報に依存していないことを確認してください。
2.10.2 サービス認証にパスワードが必要な場合、使用されるサービスアカウントがデフォルトの資格情報でないことを確認してください。(例えば、root/rootやadmin/adminは、一部のサービスのインストール時にデフォルトになっています)。
2.10.3 パスワードがオフラインリカバリ攻撃、ローカルシステムアクセスを含む、十分な保護で保存されていることを確認してください。
2.10.4 パスワード、データベースとの統合、第三者システム、シードと内部の秘密、APIキーが安全に管理され、ソースコードやソースコードリポジトリ内に含まれていないことを確認してください。そのようなストレージは、オフライン攻撃に対抗するべきです。セキュアなソフトウェアキーストア(L1)、ハードウェアTPM、またはHSM(L3)の使用がパスワードの保存に推奨されています。
3.1.1 アプリケーションがセッショントークンをURLパラメータで決して公開しないことを確認してください。
3.2.1 アプリケーションがユーザー認証時に新しいセッショントークンを生成することを確認してください。
3.2.2 セッショントークンが少なくとも64ビットのエントロピーを持っていることを確認してください。
3.2.3 アプリケーションが、適切にセキュリティが確保されたクッキー（セクション3.4を参照）やHTML 5のセッションストレージなどの安全な方法を使用して、ブラウザにセッショントークンのみを保存することを確認してください。
3.2.4 セッショントークンが承認された暗号化アルゴリズムを使用して生成されていることを確認してください。
3.3.1 ログアウトと有効期限がセッショントークンを無効にすることを確認してください。これにより、戻るボタンや下流の依存パーティーが認証済みのセッションを再開しないようにします。これには、依存パーティー間でも含まれます。
3.3.2 認証器がユーザーにログインしたままでいることを許可する場合、アクティブに使用されているときやアイドル状態の後に定期的に再認証が行われることを確認してください。
3.3.3 パスワードの変更（パスワードのリセット/回復を含む）が成功した後に、他のすべてのアクティブなセッションを終了するオプションがアプリケーションに存在することを確認してください。また、これがアプリケーション全体、連携ログイン（存在する場合）、および任意の依存関係者に対して効果的であることを確認してください。
3.3.4 ユーザーが現在アクティブなセッションやデバイスのすべてを表示し、（ログイン情報を再入力した後に）ログアウトできることを確認してください。
3.4.1 クッキーベースのセッショントークンが 'Secure' 属性を設定していることを確認してください。
3.4.2 クッキーベースのセッショントークンが 'HttpOnly' 属性を設定していることを確認してください。
3.4.3 クッキーベースのセッショントークンが 'SameSite' 属性を利用して、クロスサイトリクエストフォージェリ攻撃への露出を制限していることを確認してください。
3.4.4 クッキーベースのセッショントークンが '__Host-'プレフィックスを使用していることを確認し、クッキーが初めて設定したホストにのみ送信されるようにします。
3.4.5 アプリケーションが他のアプリケーションと共にドメイン名の下で公開され、セッションクッキーを設定または使用する可能性があり、そのセッションクッキーが公開される場合、クッキーベースのセッショントークンのパス属性を可能な限り最も正確なパスを使用して設定することを確認してください。
3.5.1 アプリケーションが、リンクされたアプリケーションとの信頼関係を形成するOAuthトークンの取り消しをユーザーに許可することを確認してください。
3.5.2 アプリケーションが静的なAPIシークレットやキーではなく、セッショントークンを使用していることを確認してください。ただし、レガシー実装では例外です。
3.5.3 ステートレスセッショントークンがデジタル署名、暗号化、およびその他の対策を使用して改ざん、包装、リプレイ、ヌル暗号、およびキー置換攻撃から保護することを確認してください。
3.7.1 アプリケーションが完全で有効なログインセッションを確保するか、または敏感な取引やアカウントの変更を許可する前に再認証または二次確認を要求することを確認してください。
4.1.1 アプリケーションが信頼されたサービス層でアクセス制御ルールを強制していることを確認してください、特にクライアント側のアクセス制御が存在し、それがバイパスされる可能性がある場合は特にです。
4.1.2 エンドユーザーが特に許可されていない限り、アクセス制御で使用されるすべてのユーザー属性、データ属性、およびポリシー情報が操作されないことを確認してください。
4.1.3 最小特権の原則が存在することを確認してください - ユーザーは、特定の認証を持っている機能、データファイル、URL、コントローラー、サービス、および他のリソースにのみアクセスできるべきです。これは、スプーフィングと特権昇格に対する保護を意味します。
4.1.5 アクセス制御が安全に失敗すること、例外が発生した場合も含めて、確認してください。
4.2.1 敏感なデータやAPIが、レコードの作成、読み取り、更新、削除を対象としたInsecure Direct Object Reference（IDOR）攻撃から保護されていることを確認してください。例えば、他人のレコードを作成または更新する、全員のレコードを閲覧する、またはすべてのレコードを削除するなどです。
4.2.2 アプリケーションまたはフレームワークが、認証済み機能を保護するための強力なanti-CSRFメカニズムを強制し、効果的なanti-automationまたはanti-CSRFが未認証機能を保護することを確認してください。
4.3.2 意図的に望まれていない限り、ディレクトリの閲覧が無効になっていることを確認してください。さらに、アプリケーションは、Thumbs.db、.DS_Store、.git、.svnフォルダなどのファイルやディレクトリのメタデータの発見や開示を許可すべきではありません。
5.1.1 アプリケーションがHTTPパラメータ汚染攻撃に対する防御を持っていることを確認してください、特にアプリケーションフレームワークがリクエストパラメータのソース（GET、POST、クッキー、ヘッダー、または環境変数）について区別をしない場合は特にです。
5.1.2 フレームワークが大量のパラメータ割り当て攻撃から保護していること、またはアプリケーションがフィールドをプライベートにするなど、安全でないパラメータ割り当てから保護するための対策を持っていることを確認してください。
5.1.3 すべての入力（HTMLフォームフィールド、RESTリクエスト、URLパラメータ、HTTPヘッダー、クッキー、バッチファイル、RSSフィードなど）がポジティブバリデーション（許可リスト）を使用して検証されていることを確認してください。
5.1.4 構造化データが強く型付けされ、許可された文字、長さ、パターン（例えば、クレジットカード番号、メールアドレス、電話番号、または郊外と郵便番号/郵便番号が一致するかどうかのような、2つの関連フィールドが合理的であることを確認する）に対して定義されたスキーマに対して検証されていることを確認してください。
5.1.5 URLのリダイレクトと転送が許可リストに記載されている宛先のみを許可することを確認し、信頼できない可能性のあるコンテンツにリダイレクトする際には警告を表示します。
5.2.1 WYSIWYGエディターや類似のものからの信頼できないHTML入力がすべて、HTMLサニタイザーライブラリやフレームワーク機能で適切にサニタイズされていることを確認してください。
5.2.2 構造化されていないデータが、許可された文字や長さなどの安全対策を強制するために無害化されていることを確認してください。
5.2.3 アプリケーションがSMTPまたはIMAPインジェクションを防ぐために、メールシステムに渡す前にユーザー入力をサニタイズすることを確認してください。
5.2.4 アプリケーションがeval()や他の動的コード実行機能の使用を避けていることを確認してください。代替案がない場合、実行前にユーザーからの任意の入力は必ずサニタイズまたはサンドボックス化されなければなりません。
5.2.6 アプリケーションがSSRF攻撃から保護していることを確認してください。これは、信頼できないデータやHTTPファイルメタデータ（ファイル名やURL入力フィールドなど）を検証または無害化し、プロトコル、ドメイン、パス、ポートの許可リストを使用することによって行われます。
5.2.7 アプリケーションがユーザー提供のスケーラブルベクターグラフィックス（SVG）スクリプト可能コンテンツをサニタイズ、無効化、またはサンドボックス化していることを確認してください。特に、インラインスクリプトから生じるXSSやforeignObjectに関連するものについては注意が必要です。
5.2.8 アプリケーションが、Markdown、CSSまたはXSLスタイルシート、BBCodeなどのユーザー提供のスクリプト可能または表現テンプレート言語コンテンツを、無効化、またはサンドボックス化することを確認してください。
5.3.1 インタープリターと必要なコンテキストに対して出力エンコーディングが関連していることを確認してください。たとえば、HTMLの値、HTMLの属性、JavaScript、URLパラメータ、HTTPヘッダ、SMTPなど、特に信頼できない入力（例えば、ユニコードやアポストロフィーを含む名前、例えばねこやO'Hara）からのものに対しては、コンテキストに応じて特定のエンコーダを使用してください。
5.3.2 出力エンコーディングがユーザーの選択した文字セットとロケールを保持し、任意のユニコード文字ポイントが有効で安全に処理されることを確認してください。
5.3.3 コンテキストに応じた、できれば自動化された - あるいは最悪の場合、手動の - 出力エスケープが、反射型、格納型、DOMベースのXSSに対して保護を提供していることを確認してください。
5.3.4 データ選択またはデータベースクエリ（例：SQL、HQL、ORM、NoSQL）がパラメータ化されたクエリ、ORM、エンティティフレームワークを使用しているか、またはデータベースインジェクション攻撃から保護されているかどうかを確認してください。
5.3.5 パラメータ化されたまたはより安全なメカニズムが存在しない場合に、コンテクスト固有の出力エンコーディングが使用されて、SQLエスケープの使用など、SQLインジェクションに対する保護など、インジェクション攻撃に対する保護を確認してください。
5.3.6 アプリケーションがJSONインジェクション攻撃、JSON eval攻撃、およびJavaScript式評価に対して保護していることを確認してください。
5.3.7 アプリケーションがLDAPインジェクションの脆弱性から保護されていることを確認するか、またはLDAPインジェクションを防ぐための特定のセキュリティコントロールが実装されていることを確認してください。
5.3.8 アプリケーションがOSコマンドインジェクションを防ぐこと、およびオペレーティングシステムの呼び出しがパラメータ化されたOSクエリを使用するか、または文脈に応じたコマンドライン出力エンコーディングを使用することを確認してください。
5.3.9 アプリケーションがローカルファイルインクルージョン（LFI）またはリモートファイルインクルージョン（RFI）攻撃から保護されていることを確認してください。
5.3.10 アプリケーションがXPathインジェクションまたはXMLインジェクション攻撃から保護されていることを確認してください。
5.4.1 アプリケーションがメモリ安全な文字列、より安全なメモリコピー、およびポインタ算術を使用してスタック、バッファ、またはヒープオーバーフローを検出または防止することを確認してください。
5.4.2 フォーマット文字列が潜在的に敵対的な入力を受け取らないこと、そして一定であることを確認してください。
5.4.3 符号、範囲、および入力検証技術が整数オーバーフローを防ぐために使用されていることを確認してください。
5.5.1 シリアル化されたオブジェクトが、敵対的なオブジェクトの作成やデータの改ざんを防ぐために、完全性チェックを使用しているか、または暗号化されていることを確認してください。
5.5.2 アプリケーションがXMLパーサーを最も制限的な設定のみに正しく制限し、外部エンティティの解決などの安全でない機能が無効化されていることを確認し、XML eXternal Entity（XXE）攻撃を防ぐことを確認してください。
5.5.3 信頼できないデータの逆シリアル化が、カスタムコードとサードパーティのライブラリ（JSON、XML、YAMLパーサーなど）の両方で避けられているか、または保護されていることを確認してください。
5.5.4 ブラウザやJavaScriptベースのバックエンドでJSONをパースする際に、JSON.parseがJSONドキュメントのパースに使用されていることを確認してください。eval()を使ってJSONを解析しないでください。
6.1.1 規制されたプライヴェートデータが、個人を特定できる情報（PII）、機密個人情報、またはEUのGDPRの対象となる可能性があるデータなど、静止状態で暗号化されて保存されていることを確認してください。
6.1.2 規制された健康データが休止状態で暗号化されて保存されていることを確認してください。例えば、医療記録、医療機器の詳細、または匿名化された研究記録などです。
6.1.3 金融口座、デフォルト、信用履歴、税務記録、給与履歴、受益者、または非匿名化された市場または研究記録など、休止状態の規制された金融データが暗号化されて保存されていることを確認してください。
6.2.1 すべての暗号化モジュールが安全に失敗し、エラーがパディングオラクル攻撃を可能にしない方法で処理されることを確認してください。
6.2.2. 業界で実証済みまたは政府が承認した暗号化アルゴリズム、モード、ライブラリが使用されていることを確認し、カスタムコードの暗号化は使用しないでください。
6.2.3 暗号化初期化ベクトル、暗号設定、およびブロックモードが、最新のアドバイスを使用して安全に設定されていることを確認してください。
6.2.4 ランダムな数値、暗号化またはハッシュアルゴリズム、キーレングス、ラウンド、暗号またはモードが、暗号化の破損に対抗するために、いつでも再設定、アップグレード、または交換できることを確認してください。
6.2.5 既知の安全でないブロックモード（例：ECBなど）、パディングモード（例：PKCS#1 v1.5など）、ブロックサイズが小さい暗号（例：Triple-DES、Blowfishなど）、および弱いハッシュアルゴリズム（例：MD5、SHA1など）が、後方互換性が必要な場合を除き、使用されていないことを確認してください。
6.2.6 ノンス、初期化ベクトル、および他の一回限りの数値が、特定の暗号化キーと一緒に一度以上使用されないことを確認してください。生成方法は、使用されているアルゴリズムに適していなければなりません。
6.2.7 暗号化されたデータが署名、認証暗号モード、またはHMACを介して認証されていることを確認し、暗号文が不正な第三者によって変更されないようにします。
6.2.8 すべての暗号化操作が一定時間であり、比較、計算、または戻り値の 'ショートサーキット' 操作がないことを確認してください。これにより情報の漏洩を避けます。
6.3.1 すべてのランダムな数値、ランダムなファイル名、ランダムなGUID、ランダムな文字列が、攻撃者によって推測されないことを意図した場合に、暗号化モジュールの承認された暗号化セキュアランダム数生成器を使用して生成されていることを確認してください。
6.3.2 ランダムなGUIDがGUID v4アルゴリズムと暗号学的に安全な疑似乱数生成器（CSPRNG）を使用して作成されていることを確認してください。他の疑似ランダム数生成器を使用して作成されたGUIDは予測可能かもしれません。
6.3.3 アプリケーションが重負荷状態にあるときでも、ランダムな数値が適切なエントロピーで生成されていることを確認するか、またはそのような状況下でアプリケーションが適切に劣化することを確認してください。
6.4.1 シークレット管理ソリューション（キーボールトなど）が、シークレットを安全に作成、保存、アクセス制御、破棄するために使用されていることを確認してください。
6.4.2 キーマテリアルがアプリケーションに露出せず、代わりに暗号化操作のためのボールトのような分離されたセキュリティモジュールを使用していることを確認してください。
7.1.1 アプリケーションが資格情報や支払い詳細をログに記録しないことを確認してください。セッショントークンは、不可逆的なハッシュ形式でのみログに保存するべきです。
7.1.2 アプリケーションが、地元のプライバシー法または関連するセキュリティポリシーで定義された他の機密データを記録しないことを確認してください。
7.1.3 アプリケーションがセキュリティ関連のイベントを記録していることを確認してください。これには、成功した認証イベントと失敗した認証イベント、アクセス制御の失敗、デシリアライゼーションの失敗、入力検証の失敗が含まれます。
7.1.4 各ログイベントが、イベントが発生した際の詳細なタイムラインの調査を可能にするための必要な情報を含んでいることを確認してください。
7.3.1 すべてのログ記録コンポーネントがデータを適切にエンコードし、ログインジェクションを防ぐことを確認してください。
7.3.3 セキュリティログが不正アクセスや改ざんから保護されていることを確認してください。
7.4.1 予期しないエラーまたはセキュリティに敏感なエラーが発生したときに、一般的なメッセージが表示されることを確認してください。可能性としては、サポート担当者が調査に使用できるユニークなIDが付与されているかもしれません。
7.4.2 コードベース全体で予想されるエラー条件と予期せぬエラー条件を考慮に入れて、例外処理（またはそれに相当する機能）が使用されていることを確認してください。
7.4.3 すべての未処理の例外をキャッチする「最終手段」のエラーハンドラが定義されていることを確認してください。
8.1.1 アプリケーションが、ロードバランサーやアプリケーションキャッシュなどのサーバーコンポーネントでキャッシュされる敏感なデータを保護していることを確認してください。
8.1.2 サーバーに保存されている機密データのキャッシュまたは一時的なコピーが、不正なアクセスから保護されているか、または権限を持つユーザーが機密データにアクセスした後にパージ/無効化されていることを確認してください。
8.1.3 アプリケーションがリクエスト内のパラメータの数を最小限に抑えることを確認してください。たとえば、隠しフィールド、Ajax変数、クッキー、ヘッダー値などです。
8.1.4 アプリケーションが異常なリクエスト数（IP、ユーザー、時間または日ごとの合計など、アプリケーションにとって意味のあるもの）を検出し、アラートを出すことができることを確認してください。
8.3.1 敏感なデータがHTTPメッセージの本文またはヘッダーでサーバーに送信され、任意のHTTP動詞からのクエリ文字列パラメーターに敏感なデータが含まれていないことを確認してください。
8.3.6 メモリダンプ攻撃を軽減するために、メモリに含まれる機密情報が必要なくなったらすぐにゼロまたはランダムデータを使用して上書きされることを確認してください。
8.3.7 暗号化が必要な機密性またはプライベート情報が、機密性と完全性の両方を提供する承認済みのアルゴリズムを使用して暗号化されていることを確認してください。
9.1.1 すべてのクライアント接続にTLSが使用されていることを確認し、安全でないまたは暗号化されていない通信にフォールバックしないことを確認してください。
9.1.3 TLSプロトコルの最新の推奨バージョンのみが有効になっていることを確認してください。例えば、TLS 1.2やTLS 1.3などです。最新版のTLSプロトコルが優先オプションであるべきです。
9.2.1 サーバーへの接続とサーバーからの接続が信頼できるTLS証明書を使用していることを確認してください。内部生成または自己署名証明書が使用される場合、サーバーは特定の内部CAおよび特定の自己署名証明書のみを信頼するように設定する必要があります。他のすべては拒否されるべきです。
9.2.2 すべての受信および送信接続、管理ポート、モニタリング、認証、API、ウェブサービスの呼び出し、データベース、クラウド、サーバーレス、メインフレーム、外部、パートナー接続を含む、すべてで暗号化通信（例：TLS）が使用されていることを確認してください。サーバーは、安全でないまたは暗号化されていないプロトコルにフォールバックしてはなりません。
9.2.3 すべての暗号化された外部システムへの接続が、機密情報や機能を含む場合には認証されていることを確認してください。
10.2.1 アプリケーションのソースコードとサードパーティのライブラリが、許可されていない電話帰宅機能やデータ収集機能を含んでいないことを確認してください。そのような機能が存在する場合、データを収集する前にユーザーの許可を得てください。
10.2.2 アプリケーションが連絡先、カメラ、マイク、位置情報などのプライバシー関連機能やセンサーに対して不必要または過度な権限を要求していないことを確認してください。
10.2.3. アプリケーションのソースコードやサードパーティのライブラリに、ハードコードされたアカウントや追加の未文書化されたアカウント、キー、コードの難読化、未文書化のバイナリブロブ、ルートキット、またはアンチデバッグ、安全でないデバッグ機能、またはそれ以外の古い、安全でない、または隠された機能が含まれていないことを確認してください。これらは、発見された場合に悪意のある方法で使用される可能性があります。
10.2.4 アプリケーションのソースコードとサードパーティのライブラリがタイムボムを含んでいないことを確認するために、日付と時間に関連する関数を検索してください。
10.2.5 アプリケーションのソースコードとサードパーティのライブラリが、サラミ攻撃、ロジックバイパス、またはロジックボムなどの悪意のあるコードを含んでいないことを確認してください。
10.2.6 アプリケーションのソースコードやサードパーティのライブラリにイースターエッグや他の望ましくない機能が含まれていないことを確認してください。
10.3.1 アプリケーションがクライアントまたはサーバーの自動更新機能を持っているか確認してください。更新は安全なチャネルを介して取得され、デジタルに署名されるべきです。アップデートコードは、アップデートをインストールまたは実行する前に、アップデートのデジタル署名を検証する必要があります。
10.3.2 アプリケーションがコード署名やサブリソースの完全性などの完全性保護を使用していることを確認してください。アプリケーションは、信頼できないソースからのインクルード、モジュール、プラグイン、コード、ライブラリなどをロードまたは実行してはなりません。これには、信頼できないソースやインターネットからのものも含まれます。
10.3.3 アプリケーションがDNSエントリーやDNSサブドメイン（期限切れのドメイン名、古いDNSポインターやCNAME、公開ソースコードリポジトリの期限切れのプロジェクト、一時的なクラウドAPI、サーバーレス関数、ストレージバケット（autogen-bucket-id.cloud.example.com）など）に依存している場合、サブドメインの乗っ取りから保護されていることを確認してください。保護策には、アプリケーションが使用するDNS名が定期的に有効期限や変更をチェックすることが含まれます。
11.1.1 アプリケーションが同じユーザーのビジネスロジックフローを順序通りに、ステップをスキップせずに処理することを確認してください。
11.1.2 アプリケーションが、すべてのステップが現実的な人間の時間で処理されるビジネスロジックフローのみを処理することを確認してください。つまり、トランザクションはあまりにも早く送信されません。
11.1.3 特定のビジネスアクションやトランザクションに対して適切な制限が設定されており、それがユーザーごとに正しく適用されていることを確認してください。
11.1.4 アプリケーションが大量のデータ流出、ビジネスロジックのリクエスト、ファイルのアップロード、またはサービス拒否攻撃などの過度な呼び出しに対抗するための反自動化コントロールを持っていることを確認してください。
11.1.5 アプリケーションがビジネスリスクや脅威に対する保護として、ビジネスロジックの制限または検証を持っていることを確認してください。これらのリスクや脅威は、脅威モデリングや類似の方法論を使用して特定されます。
11.1.6 アプリケーションが「チェックの時間から使用の時間」（TOCTOU）の問題や、他のレースコンディションによる敏感な操作の問題を抱えていないことを確認してください。
12.1.1 アプリケーションがストレージを満たす可能性のある大きなファイルや、サービス拒否を引き起こす可能性のあるファイルを受け入れないことを確認してください。
12.1.3 ファイルサイズの制限とユーザーごとの最大ファイル数が適用されていることを確認してください。これにより、一人のユーザーが多数のファイルや過大なファイルでストレージを埋め尽くすことを防ぎます。
12.3.1 ユーザーが提出したファイル名のメタデータがシステムやフレームワークのファイルシステムに直接使用されていないこと、そしてパストラバーサルに対抗するためにURL APIが使用されていることを確認してください。
12.3.2 ユーザーが提出したファイル名のメタデータが検証されるか無視されることを確認してください。これにより、ローカルファイル（LFI）の開示、作成、更新、または削除を防ぎます。
12.3.3 ユーザーが提出したファイlenameメタデータが検証されるか無視されることを確認してください。これにより、リモートファイルの開示または実行がリモートファイルインクルージョン（RFI）またはサーバーサイドリクエストフォージェリ（SSRF）攻撃を介して防止されます。
12.3.4 アプリケーションが反射ファイルダウンロード（RFD）を防ぐことを確認します。これは、JSON、JSONP、またはURLパラメーターでユーザーが提出したファイル名を検証または無視することによって行います。レスポンスのContent-Typeヘッダーはtext/plainに設定する必要があり、Content-Dispositionヘッダーは固定のファイル名を持つべきです。
12.3.5 信頼できないファイルのメタデータがシステムAPIやライブラリーと直接使用されていないことを確認し、OSコマンドインジェクションに対する保護を確保してください。
12.3.6 アプリケーションが信頼できないソースからの機能を含んで実行しないことを確認してください。たとえば、未確認のコンテンツ配信ネットワーク、JavaScriptライブラリ、node npmライブラリ、またはサーバーサイドのDLLなどです。
12.4.1 信頼できないソースから取得したファイルが、ウェブルートの外部に、限定的な権限で保存されていることを確認してください。
12.5.1 ウェブ層が特定のファイル拡張子のみのファイルを提供するように設定されていることを確認し、意図しない情報やソースコードの漏洩を防ぎます。たとえば、バックアップファイル（例：.bak）、一時的な作業ファイル（例：.swp）、圧縮ファイル（.zip、.tar.gzなど）や、エディターでよく使われる他の拡張子は、必要な場合を除いてブロックするべきです。
12.5.2 アップロードされたファイルへの直接のリクエストがHTML/JavaScriptコンテンツとして実行されることがないことを確認してください。
12.6.1 ウェブまたはアプリケーションサーバーが、サーバーがリクエストを送信したり、データ/ファイルをロードすることができるリソースまたはシステムの許可リストで設定されていることを確認してください。
13.1.1 すべてのアプリケーションコンポーネントが同じエンコーディングとパーサーを使用していることを確認し、SSRFやRFI攻撃で使用される可能性のある異なるURIまたはファイル解析動作を利用した解析攻撃を防ぎます。
13.1.3 APIのURLがAPIキー、セッショントークンなどの機密情報を公開していないことを確認してください。
13.1.4 URIで、コントローラーやルーターによるプログラムまたは宣言的なセキュリティによって強制され、リソースレベルで、モデルベースの権限によって強制される認証決定が行われていることを確認してください。
13.1.5 予期しないまたは欠落しているコンテンツタイプを含むリクエストが、適切なヘッダー（HTTPレスポンスステータス406 Unacceptableまたは415 Unsupported Media Type）で拒否されることを確認してください。
13.2.1 有効になっているRESTful HTTPメソッドがユーザーやアクションに対して有効な選択肢であることを確認してください。例えば、通常のユーザーが保護されたAPIやリソースに対してDELETEやPUTを使用するのを防ぐなどです。
13.2.2 入力を受け入れる前に、JSONスキーマの検証が行われ、確認されていることを確認してください。
13.2.3 RESTfulウェブサービスがクッキーを利用している場合、ダブルサブミットクッキーパターン、CSRFノンス、またはOriginリクエストヘッダーチェックのいずれか一つ以上を使用して、クロスサイトリクエストフォージェリから保護されていることを確認してください。
13.2.5 RESTサービスが、application/xmlやapplication/jsonなど、期待されるContent-Typeを明示的にチェックしていることを確認してください。
13.2.6 メッセージヘッダーとペイロードが信頼性があり、転送中に変更されていないことを確認してください。輸送用の強力な暗号化（TLSのみ）が必要な場合も多く、これにより機密性と完全性の保護の世界が提供されます。メッセージごとのデジタル署名は、高セキュリティアプリケーションのトランスポート保護に加えて追加の保証を提供することができますが、それには追加の複雑さと利益と比較して考えるべきリスクが伴います。
13.3.1 XSDスキーマの検証が行われ、正しく形成されたXMLドキュメントが確保されていることを確認してください。その後、データの処理が行われる前に各入力フィールドの検証が行われます。
13.3.2 メッセージのペイロードがWS-Securityを使用して署名されていることを確認し、クライアントとサービス間の信頼性の高い転送を確保してください。
13.4.1 高価な、ネストされたクエリによるGraphQLまたはデータレイヤー表現のサービス拒否（DoS）を防ぐために、クエリ許可リストまたは深度制限と量制限の組み合わせが使用されていることを確認してください。より高度なシナリオの場合、クエリコスト分析を使用すべきです。
14.1.3 アプリケーションサーバーと使用中のフレームワークの推奨事項に従って、サーバー設定が強化されていることを確認してください。
14.2.2 すべての不要な機能、ドキュメンテーション、サンプルアプリケーション、設定が削除されていることを確認してください。
14.2.3 アプリケーションのアセット（JavaScriptライブラリ、CSS、ウェブフォントなど）が、コンテンツデリバリーネットワーク（CDN）や外部プロバイダーに外部ホストされている場合、Subresource Integrity（SRI）がアセットの完全性を検証するために使用されていることを確認してください。
14.2.4 第三者のコンポーネントが事前に定義された、信頼できる、継続的にメンテナンスされているリポジトリから来ていることを確認してください。
14.3.2 14.3.2 - 本番環境でのWebまたはアプリケーションサーバーおよびアプリケーションフレームワークのデバッグモードが無効化されていることを確認します。これにより、デバッグ機能、開発者コンソール、意図しないセキュリティ情報の開示が排除されます。
14.3.3 HTTPヘッダーやHTTPレスポンスの一部がシステムコンポーネントの詳細なバージョン情報を公開していないことを確認してください。
14.4.1 すべてのHTTPレスポンスにContent-Typeヘッダーが含まれていることを確認してください。また、コンテンツタイプがtext/*、/+xml、およびapplication/xmlの場合は、安全な文字セット（例：UTF-8、ISO-8859-1）を指定してください。コンテンツは提供されたContent-Typeヘッダーと一致しなければなりません。
14.4.2 すべてのAPIレスポンスにContent-Disposition: attachment; filename='api.json'ヘッダー（またはコンテンツタイプに適した他のファイル名）が含まれていることを確認してください。
14.4.3 HTML、DOM、JSON、JavaScriptインジェクションの脆弱性のようなXSS攻撃の影響を軽減するのに役立つContent Security Policy（CSP）レスポンスヘッダーが配置されていることを確認してください。
14.4.4 すべてのレスポンスに「X-Content-Type-Options: nosniff」ヘッダーが含まれていることを確認してください。
14.4.5 すべての応答とすべてのサブドメインにStrict-Transport-Securityヘッダーが含まれていることを確認してください。例えば、Strict-Transport-Security: max-age=15724800; includeSubdomainsのように。
14.4.6 信頼できない第三者に対してRefererヘッダーを通じてURLの機密情報を公開しないように、適切なReferrer-Policyヘッダーが含まれていることを確認してください。
14.4.7 Webアプリケーションのコンテンツがデフォルトで第三者のサイトに埋め込まれないことを確認し、適切なContent-Security-Policy: frame-ancestorsおよびX-Frame-Optionsレスポンスヘッダーを使用して、必要な場所でのみ正確なリソースの埋め込みが許可されるようにします。
14.5.1 アプリケーション/APIで使用されているHTTPメソッドのみをアプリケーションサーバーが受け入れることを確認し、プレフライトOPTIONSを含む、アプリケーションのコンテキストに無効なリクエストがあった場合にはログ/アラートを出すことを確認してください。
14.5.2 提供されたOriginヘッダーが認証やアクセス制御の決定に使用されていないことを確認してください。なぜなら、Originヘッダーは攻撃者によって簡単に変更できるからです。
14.5.3 Cross-Origin Resource Sharing（CORS）のAccess-Control-Allow-Originヘッダーが、信頼できるドメインとサブドメインの厳格な許可リストを使用してマッチングし、'null'オリジンをサポートしていないことを確認してください。
14.5.4 信頼できるプロキシやSSOデバイスによって追加されたHTTPヘッダー、例えばベアラートークンなどが、アプリケーションによって認証されていることを確認してください。