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

OWASP アプリケーションセキュリティ検証標準 (ASVS) は、アプリケーションレベルのセキュリティ要件の包括的なフレームワークを定義しています。これは、安全なソフトウェアを設計、構築、検証するためのコミュニティ主導のベースラインであり、アーキテクト、開発者、テスター、リスク管理チームに役立ちます。

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

標準のバージョン 5.0 は、以下の主要な原則に焦点を当てています。

  • スコープと重点の明確化: 標準を 4 つの柱（アプリケーション、セキュリティ、検証、および標準）を中心に再構成し、規範的な実施手順ではなく、達成すべきことに焦点を当てています。
  • 文書化されたセキュリティ上の意思決定: 新しいメタ要件により、トレーサビリティ、整合性、および検証可能性を確保するために、設計上の判断を文書化することが義務付けられています。
  • 簡素化されたレベルと利用しやすさ: 3 つのレベル（L1〜L3）を維持しつつ、対象範囲を明確化しています。レベル 1 は一般的な攻撃に対する基本的な耐性を提供し、レベル 2 は標準的なベストプラクティスを表し、レベル 3 は高保証が求められる重要なシステムに適用されます。
  • 再構成および拡張されたコンテンツ: 現在、約 350 の要件が 17 の章にまたがっており、より明確な構成と、移行のための v4.0 との対応付けが導入されています。

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

この AppScan Enterprise 業界標準レポートは、2025 年 5 月に発効した OWASP Application Security Verification Standard (ASVS) V5.0.0 で定義されたセキュリティ検証レベルに照らして、対象のアプリケーションを評価します。

アプリケーションセキュリティ検証標準 (ASVS):

アプリケーションセキュリティ検証標準は、OWASP によって開発および保守されています。この標準は、Creative Commons Attribution ShareAlike 3.0 ライセンスの下でリリースされています。詳しくは、OWASP Application Security Verification Standard V5.0.0 を参照してください。

Web アプリケーションのセキュリティー保護の詳細については、HCL AppScan: Advanced Application Security Testing を参照してください。

OWASP Application Security Verification Standard (ASVS) レポート内の脆弱性

ID 名前
1.1.2 アプリケーションが、対象となるインタープリターで使用される直前の最終段階、またはインタープリター自体において、出力エンコーディングおよびエスケープを実行することを検証します。
1.2.1 HTTP レスポンス、HTML ドキュメント、または XML ドキュメントの出力エンコーディングが、メッセージやドキュメントの構造の変更を防ぐために、HTML 要素、HTML 属性、HTML コメント、CSS、HTTP ヘッダーフィールドなど、それぞれの必要なコンテキストに適したものになっていることを検証します。
1.2.3 JavaScript コンテンツ（JSON を含む）を動的に構築する際に、メッセージまたはドキュメント構造の変更を回避し、JavaScript および JSON インジェクションを防ぐため、出力エンコーディングまたはエスケープが使用されていることを検証します。
1.2.4 データの選択処理またはデータベース・クエリー（例: SQL、HQL、NoSQL、Cypher）が、パラメーター化クエリー、ORM、エンティティー・フレームワークを使用しているか、または SQL インジェクションやその他のデータベース・インジェクション攻撃から保護されていることを検証します。これはストアード・プロシージャーの作成時にも該当します。
1.2.5 アプリケーションが OS コマンド・インジェクションから保護されていること、およびオペレーティング・システムの呼び出しで、パラメーター化された OS クエリーを使用するか、コンテキストに応じたコマンドライン出力エンコーディングを使用していることを検証します。
1.2.7 クエリーのパラメーター化またはプリコンパイル済みクエリーを使用して、アプリケーションが XPath インジェクション攻撃から保護されていることを検証します。
1.3.1 WYSIWYG エディターまたは類似のものからのすべての信頼されていない HTML 入力が、よく知られた安全な HTML サニタイズ・ライブラリーまたはフレームワーク機能を使用してサニタイズされていることを検証します。
1.3.2 アプリケーションが eval() やその他の動的コード実行機能 (Spring Expression Language (SpEL) など) の使用を回避していることを検証します。代替手段がない場合は、実行対象に含めるあらゆるユーザー入力を、実行前にサニタイズする必要があります。
1.3.3 潜在的に危険なコンテキストに渡されるデータが、安全対策を施すために事前にサニタイズされていることを検証します。例えば、そのコンテキストで安全な文字のみを許可し、長すぎる入力をトリミングすることです。
1.3.4 ユーザー提供の Scalable Vector Graphics (SVG) スクリプト可能コンテンツが、アプリケーションにとって安全なタグと属性（描画用のグラフィック要素など）のみを含むように検証またはサニタイズされていることを検証します。例えば、スクリプトや foreignObject を含まないようにします。
1.3.5 アプリケーションが、Markdown、CSS または XSL スタイルシート、BBCode などのユーザー提供のスクリプト可能または式テンプレート言語コンテンツをサニタイズまたは無効化していることを検証します。
1.3.6 信頼されていないデータをプロトコル、ドメイン、パス、およびポートの許可リストに照らして検証し、別のサービスを呼び出す前に潜在的に危険な文字をサニタイズすることにより、アプリケーションがサーバーサイド・リクエスト・フォージェリー (SSRF) 攻撃から保護されていることを検証します。
1.3.10 使用時に予期しない、または悪意のある形で解釈される可能性のあるフォーマット文字列が、処理前にサニタイズされていることを検証します。
1.3.11 SMTP または IMAP インジェクションから保護するために、アプリケーションがメール・システムに渡す前にユーザー入力をサニタイズしていることを検証します。
1.4.1 アプリケーションが、メモリー安全な文字列処理、より安全なメモリー・コピー、およびポインター演算を使用して、スタック、バッファー、またはヒープのオーバーフローを検出または防止していることを検証します。
1.4.2 整数オーバーフローを防止するために、符号、範囲、および入力検証技法が使用されていることを検証します。
1.5.1 アプリケーションが XML パーサーを制限的な構成で設定し、外部エンティティーの解決などの安全でない機能を無効化して、XML eXternal Entity (XXE) 攻撃を防止していることを検証します。
1.5.2 信頼されていないデータのデシリアライゼーションにおいて、オブジェクト・タイプの許可リストの使用やクライアント定義のオブジェクト・タイプの制限など、安全な入力処理が適用されており、デシリアライゼーション攻撃を防止していることを検証します。明示的に安全でないと定義されているデシリアライゼーション・メカニズムは、信頼されていない入力で使用してはなりません。
1.5.3 アプリケーションで同じデータ・タイプに対して使用される異なるパーサー（例: JSON パーサー、XML パーサー、URL パーサー）が、一貫した方法で解析を行い、同じ文字エンコーディング・メカニズムを使用していることを検証します。これにより、JSON 相互運用性の脆弱性や、URI またはファイルの解析動作の違いがリモート・ファイル・インクルージョン (RFI) またはサーバーサイド・リクエスト・フォージェリー (SSRF) 攻撃で悪用されるといった問題を回避します。
2.2.1 入力に対するビジネス上または機能上の期待を満たすよう、入力が検証されていることを確認します。これは、値、パターン、および範囲の許可リストに対するポジティブバリデーションを使用するか、または事前定義されたルールに従って、入力を期待される構造および論理的な制限と比較することに基づく必要があります。L1 の場合、これは特定のビジネスまたはセキュリティーの決定を行うために使用される入力に焦点を当てることができます。L2 以上の場合、これはすべての入力に適用する必要があります。
2.2.2 アプリケーションが、信頼できるサービス層で入力検証を実施するように設計されていることを検証します。クライアントサイドの検証はユーザビリティーを向上させるため推奨されますが、セキュリティー・コントロールとして依拠してはなりません。
2.2.3 アプリケーションが、関連するデータ項目の組み合わせが事前定義されたルールに従って妥当であることを保証していることを検証します。
2.3.1 アプリケーションが、同一ユーザーのビジネスロジックフローを、ステップをスキップすることなく、期待される順序でのみ処理することを検証します。
2.3.2 ビジネスロジックの欠陥が悪用されることを防ぐために、アプリケーションのドキュメントに従ってビジネスロジックの制限が実装されていることを検証します。
2.4.1 データの流出、不要データの生成、クォータの枯渇、レート制限の違反、サービス拒否、または高コストなリソースの過剰使用につながる可能性のあるアプリケーション機能への過度な呼び出しから保護するための自動化防止制御が実装されていることを検証します。
2.4.2 ビジネスロジックフローが現実的な人間の操作時間を必要とし、過度に高速なトランザクション送信を防止していることを検証します。
3.2.1 HTTP レスポンスのコンテンツまたは機能がブラウザーによって不正なコンテキストでレンダリングされることを防止するセキュリティ制御が実装されていることを検証します（例: API、ユーザーがアップロードしたファイル、またはその他のリソースが直接リクエストされた場合）。可能な制御としては、HTTP リクエストヘッダーフィールド（Sec-Fetch-\* など）が正しいコンテキストであることを示さない限りコンテンツを提供しないこと、Content-Security-Policy ヘッダーフィールドの sandbox ディレクティブを使用すること、または Content-Disposition ヘッダーフィールドで attachment ディスポジションタイプを使用することが挙げられます。
3.3.1 Cookie に 'Secure' 属性が設定されていること、および Cookie 名に '\__Host-' プレフィックスが使用されていない場合は、Cookie 名に '__Secure-' プレフィックスを使用する必要があることを検証します。
3.3.2 ユーザーインターフェースのリドレス攻撃や、一般にクロスサイトリクエストフォージェリ（CSRF）として知られるブラウザーベースのリクエスト偽造攻撃にさらされるリスクを制限するために、各 Cookie の 'SameSite' 属性値が Cookie の目的に応じて設定されていることを検証します。
3.3.3 Cookie が他のホストと共有されるように明示的に設計されている場合を除き、Cookie 名に '__Host-' プレフィックスが使用されていることを検証します。
3.3.4 Cookie の値がクライアント側スクリプト（セッショントークンなど）からアクセスされることを意図していない場合、その Cookie に 'HttpOnly' 属性が設定されていること、および同じ値（例: セッショントークン）が 'Set-Cookie' ヘッダーフィールドを介してのみクライアントに転送されることを検証します。
3.4.1 HTTP Strict Transport Security（HSTS）ポリシーを適用するために、すべてのレスポンスに Strict-Transport-Security ヘッダーフィールドが含まれていることを検証します。最大有効期間は少なくとも 1 年でなければならず、L2 以上では、ポリシーはすべてのサブドメインにも適用される必要があります。
3.4.2 Cross-Origin Resource Sharing（CORS）の Access-Control-Allow-Origin ヘッダーフィールドがアプリケーションによって固定値であること、または Origin HTTP リクエストヘッダーフィールドの値が使用される場合は、信頼されたオリジンの許可リストに対して検証されていることを検証します。'Access-Control-Allow-Origin: *' を使用する必要がある場合、レスポンスに機密情報が含まれていないことを検証します。
3.4.3 悪意のある JavaScript の実行を制限するために、ブラウザーが信頼できるコンテンツまたはリソースのみを読み込み、実行することを確実にするディレクティブを定義した Content-Security-Policy レスポンスヘッダーフィールドが HTTP レスポンスに含まれていることを検証します。最低限、object-src 'none' および base-uri 'none' ディレクティブを含み、許可リストを定義するか、nonce またはハッシュを使用するグローバルポリシーを使用する必要があります。L3 アプリケーションの場合、nonce またはハッシュを使用したレスポンスごとのポリシーを定義する必要があります。
3.4.4 すべての HTTP レスポンスに 'X-Content-Type-Options: nosniff' ヘッダーフィールドが含まれていることを検証します。これにより、ブラウザーは指定されたレスポンスに対してコンテンツスニッフィングや MIME タイプの推測を行わず、レスポンスの Content-Type ヘッダーフィールドの値が対象リソースの種類と一致していることを要求するようになります。例えば、スタイルシートのリクエストに対するレスポンスは、その Content-Type が 'text/css' である場合にのみ受け入れられます。これにより、ブラウザーによる Cross-Origin Read Blocking（CORB）機能の使用も有効になります。
3.4.5 'Referer' HTTP リクエストヘッダーフィールドを介したサードパーティサービスへの技術的に機密性の高いデータの漏洩を防止するために、アプリケーションがリファラーポリシーを設定していることを検証します。これは、Referrer-Policy HTTP レスポンスヘッダーフィールドまたは HTML 要素の属性を使用して行うことができます。機密データには、URL 内のパスおよびクエリデータが含まれる可能性があり、内部の非公開アプリケーションの場合はホスト名も含まれます。
3.4.6 Web アプリケーションが、すべての HTTP レスポンスに対して Content-Security-Policy ヘッダーフィールドの frame-ancestors ディレクティブを使用して、デフォルトで埋め込みができないようにし、特定のリソースの埋め込みは必要な場合にのみ許可されるようにしていることを検証します。X-Frame-Options ヘッダーフィールドはブラウザーでサポートされていますが、廃止されており、これに依拠すべきではないことに注意してください。
3.5.1 アプリケーションが、許可されていないクロスオリジンリクエストによる機密機能の使用を防ぐために CORS プリフライトメカニズムに依存していない場合、それらのリクエストがアプリケーション自体から発信されたものであることを検証していることを確認します。これは、偽造防止トークンを使用し、それを検証するか、CORS セーフリストに含まれないリクエストヘッダーフィールドである追加の HTTP ヘッダーフィールドを要求することで実現できます。これは、ブラウザーベースのリクエスト偽造攻撃（一般にクロスサイトリクエストフォージェリ（CSRF）として知られる）を防御するためのものです。
3.5.2 アプリケーションが CORS プリフライトメカニズムに依存して、許可されていないクロスオリジンでの機密機能の使用を防止している場合、CORS プリフライトリクエストをトリガーしないリクエストでその機能を呼び出すことができないことを検証します。これには、'Origin' および 'Content-Type' リクエストヘッダーフィールドの値を確認するか、CORS セーフリストに含まれないヘッダーフィールドである追加のヘッダーフィールドを使用することが必要になる場合があります。
3.5.3 機密機能への HTTP リクエストが、POST、PUT、PATCH、DELETE などの適切な HTTP メソッドを使用し、HTTP 仕様で「安全」と定義されている HEAD、OPTIONS、GET などのメソッドを使用していないことを検証します。あるいは、Sec-Fetch-* リクエストヘッダーフィールドの厳密な検証を使用して、リクエストが不適切なクロスオリジン呼び出し、ナビゲーションリクエスト、または予期されていないリソースの読み込み（画像ソースなど）から発信されたものではないことを確認できます。
3.5.4 同一オリジンポリシーによって提供される制限（あるオリジンによって読み込まれたドキュメントまたはスクリプトが別のオリジンのリソースとどのように対話できるか、および Cookie に対するホスト名ベースの制限を含む）を活用するために、個別のアプリケーションが異なるホスト名でホストされていることを検証します。
3.6.1 JavaScript ライブラリ、CSS、Web フォントなどのクライアント側アセットが外部（例: コンテンツ配信ネットワーク上）でホストされるのは、リソースが静的かつバージョン管理されており、サブリソース完全性（SRI）を使用してアセットの整合性が検証される場合に限られることを検証してください。これが不可能な場合は、各リソースについて、それを正当化する文書化されたセキュリティ上の判断が必要です。
3.7.1 アプリケーションが、引き続きサポートされ安全と見なされるクライアント側テクノロジーのみを使用していることを検証してください。この要件を満たさないテクノロジーの例としては、NSAPI プラグイン、Flash、Shockwave、ActiveX、Silverlight、NACL、またはクライアント側 Java アプレットなどがあります。
3.7.3 アプリケーションの制御外の URL にユーザーがリダイレクトされる際に、ナビゲーションをキャンセルするオプションとともに通知が表示されることを検証してください。
4.1.1 メッセージ本文を含むすべての HTTP レスポンスに、レスポンスの実際の内容に一致する Content-Type ヘッダーフィールドが含まれていることを検証してください。これには、IANA メディアタイプに従って安全な文字エンコーディング（例: UTF-8、ISO-8859-1）を指定する charset パラメーターが含まれ、例として 'text/*'、'*/+xml'、'*/xml' などがあります。
4.1.4 アプリケーションまたはその API によって明示的にサポートされている HTTP メソッド（プリフライトリクエスト時の OPTIONS を含む）のみが使用可能であり、未使用のメソッドがブロックされていることを検証してください。
4.1.5 高度に機密性の高いリクエストやトランザクション、または複数のシステムを経由するものに対して、トランスポート保護に加えて追加の保証を提供するために、メッセージごとのデジタル署名が使用されていることを検証してください。
4.3.1 高コストでネストの深いクエリの結果として発生する GraphQL またはデータレイヤー式のサービス拒否（DoS）を防止するために、クエリ許可リスト、深度制限、件数制限、またはクエリコスト分析が使用されていることを検証してください。
5.2.1 アプリケーションが、パフォーマンスの低下やサービス拒否攻撃を引き起こすことなく処理できるサイズのファイルのみを受け入れることを検証してください。
5.2.4 単一のユーザーが過剰な数のファイルや極端に大きなファイルでストレージを埋め尽くすことができないように、ファイルサイズのクォータおよびユーザーあたりの最大ファイル数が適用されていることを検証してください。
5.3.1 信頼できない入力によってアップロードまたは生成され、パブリックフォルダーに保存されたファイルが、HTTP リクエストで直接アクセスされた際にサーバー側のプログラムコードとして実行されないことを検証してください。
5.3.2 アプリケーションがファイル操作のためにファイルパスを作成する際に、ユーザーが送信したファイル名の代わりに、内部で生成されたデータまたは信頼できるデータを使用していること、またはユーザーが送信したファイル名やファイルメタデータを使用する必要がある場合には、厳格な検証とサニタイズが適用されていることを検証してください。これは、パストラバーサル、ローカルまたはリモートファイルインクルージョン（LFI、RFI）、およびサーバー側リクエストフォージェリ（SSRF）攻撃から保護するためです。
5.4.1 アプリケーションが、JSON、JSONP、または URL パラメーター内を含め、ユーザーが送信したファイル名を検証または無視し、レスポンスの Content-Disposition ヘッダーフィールドでファイル名を指定していることを検証してください。
6.1.3 アプリケーションに複数の認証経路が含まれる場合、それらすべてが文書化されており、さらに、それらに対して一貫して適用されなければならないセキュリティコントロールおよび認証強度も併せて文書化されていることを検証してください。
6.2.1 ユーザーが設定するパスワードが少なくとも 8 文字の長さであることを検証してください。ただし、最低 15 文字が強く推奨されます。
6.2.9 少なくとも 64 文字のパスワードが許可されていることを検証してください。
6.3.1 クレデンシャルスタッフィングやパスワードの総当たり攻撃などを防止するためのコントロールが、アプリケーションのセキュリティ文書に従って実装されていることを検証してください。
6.3.2 デフォルトのユーザーアカウント（例: 'root'、'admin'、または 'sa'）がアプリケーションに存在しないか、無効化されていることを検証してください。
6.3.3 アプリケーションにアクセスするために、多要素認証メカニズムまたは単一要素認証メカニズムの組み合わせのいずれかが使用されていることを検証してください。L3 の場合、要素の 1 つは、認証の意図をユーザーが開始するアクション（FIDO ハードウェアキーのボタン押下や携帯電話での操作など）を要求することにより、フィッシング攻撃に対する侵害およびなりすまし耐性を提供するハードウェアベースの認証メカニズムでなければなりません。この要件における考慮事項のいずれかを緩和するには、十分に文書化された根拠と包括的な緩和コントロール一式が必要です。
6.3.6 メールが単一要素または多要素の認証メカニズムとして使用されていないことを検証してください。
6.4.1 システムが生成する初期パスワードまたはアクティベーションコードが、安全かつランダムに生成され、既存のパスワードポリシーに従い、短期間の経過後または初回使用後に失効することを検証してください。これらの初期シークレットが長期的に使用するパスワードになることを許可してはなりません。
6.4.2 パスワードヒントまたは知識ベースの認証（いわゆる「秘密の質問」）が存在しないことを検証してください。
6.5.1 ルックアップシークレット、帯域外認証リクエストまたはコード、および時間ベースのワンタイムパスワード（TOTP）が、一度しか正常に使用できないことを検証してください。
6.5.2 アプリケーションのバックエンドに保存される場合、112 ビット未満のエントロピー（19 個のランダムな英数字または 34 個のランダムな数字）を持つルックアップシークレットが、32 ビットのランダムソルトを組み込んだ承認済みのパスワード保存ハッシュアルゴリズムでハッシュ化されていることを検証してください。シークレットが 112 ビット以上のエントロピーを持つ場合は、標準のハッシュ関数を使用できます。
6.5.3 ルックアップシークレット、帯域外認証コード、および時間ベースのワンタイムパスワードシードが、予測可能な値を回避するために暗号論的に安全な擬似乱数生成器（CSPRNG）を使用して生成されていることを検証してください。
7.2.2 アプリケーションがセッション管理に、動的に生成される自己完結型トークンまたは参照トークンを使用していること、すなわち静的な API シークレットやキーを使用していないことを検証してください。
7.2.3 参照トークンがユーザーセッションを表すために使用される場合、それらが一意であり、暗号論的に安全な擬似乱数生成器（CSPRNG）を使用して生成され、少なくとも 128 ビットのエントロピーを持つことを検証する。
7.2.4 アプリケーションが、再認証を含むユーザー認証時に新しいセッショントークンを生成し、現在のセッショントークンを無効化することを検証する。
7.3.2 リスク分析および文書化されたセキュリティ上の決定に従って再認証が強制されるよう、セッションの絶対最大有効期間が設定されていることを検証する。
7.4.1 セッションの終了がトリガーされた場合（ログアウトや有効期限切れなど）、アプリケーションがそのセッションのそれ以上の使用を許可しないことを検証する。参照トークンまたはステートフルセッションの場合、これはアプリケーションバックエンドでセッションデータを無効化することを意味する。自己完結型トークンを使用するアプリケーションでは、終了済みトークンのリストの管理、ユーザーごとの日時より前に生成されたトークンの拒否、またはユーザーごとの署名キーのローテーションなどのソリューションが必要となる。
7.4.3 いずれかの認証要素の変更または削除が成功した後（リセットまたはリカバリーによるパスワード変更、および存在する場合はMFA設定の更新を含む）、アプリケーションが他のすべてのアクティブセッションを終了するオプションを提供することを検証する。
7.5.1 メールアドレス、電話番号、MFA構成、またはアカウントリカバリーに使用されるその他の情報など、認証に影響を与える可能性のある機密性の高いアカウント属性の変更を許可する前に、アプリケーションが完全な再認証を要求することを検証する。
7.5.2 ユーザーが現在アクティブなすべてのセッションを表示し、（少なくとも1つの要素で再度認証した上で）任意のまたはすべてのセッションを終了できることを検証する。
8.1.1 認可に関するドキュメントが、コンシューマーの権限およびリソース属性に基づいて、機能レベルおよびデータ固有のアクセスを制限するルールを定義していることを検証する。
8.2.1 アプリケーションが、明示的な権限を持つコンシューマーに対してのみ機能レベルのアクセスを許可していることを検証する。
8.2.2 安全でない直接オブジェクト参照（IDOR）および不適切なオブジェクトレベル認可（BOLA）を軽減するために、アプリケーションが特定のデータ項目に対する明示的な権限を持つコンシューマーに対してのみデータ固有のアクセスを許可していることを検証する。
8.3.1 アプリケーションが信頼できるサービス層で認可ルールを適用し、クライアントサイドJavaScriptなど、信頼されていないコンシューマーが操作可能なコントロールに依存していないことを検証する。
8.4.2 管理インターフェースへのアクセスが、継続的なコンシューマーのID検証、デバイスのセキュリティ態勢評価、およびコンテキストに基づくリスク分析を含む複数のセキュリティ層を組み込んでおり、ネットワークの場所や信頼されたエンドポイントが不正アクセスの可能性を低減する可能性はあるものの、認可の唯一の要素とならないことを検証する。
9.1.1 自己完結型トークンの内容を受け入れる前に、改ざん防止のため、トークンがそのデジタル署名またはMACを用いて検証されていることを検証する。
10.4.9 悪意のあるクライアントやトークンの盗難のリスクを軽減するために、認可サーバーのユーザーインターフェースを使用して、認可されたユーザーがリフレッシュトークンおよびリファレンスアクセストークンを失効させることができることを検証する。
11.1.2 暗号インベントリが実施され、維持管理され、定期的に更新されており、アプリケーションで使用されるすべての暗号鍵、アルゴリズム、および証明書が含まれていることを検証する。また、システム内で鍵を使用できる場所と使用できない場所、および鍵を使用して保護できるデータの種類と保護できないデータの種類も文書化する必要がある。
11.2.1 暗号操作には、業界で検証された実装（ライブラリおよびハードウェアアクセラレーションによる実装を含む）が使用されていることを検証する。
11.2.2 暗号の破綻に対して保護するために、乱数、認証付き暗号化、MAC、またはハッシュアルゴリズム、鍵長、ラウンド数、暗号方式およびモードをいつでも再構成、アップグレード、または交換できるように、アプリケーションが暗号アジリティを備えた設計になっていることを検証する。同様に、鍵やパスワードの置き換え、およびデータの再暗号化も可能でなければならない。これにより、承認されたPQC方式または標準の高保証実装が広く利用可能になった際に、耐量子暗号（PQC）へのシームレスなアップグレードが可能になる。
11.2.4 情報漏えいを防ぐために、すべての暗号操作が定数時間で実行され、比較、計算、またはreturn文において「ショートサーキット」操作がないことを検証する。
11.2.5 すべての暗号モジュールが安全に失敗し、パディングオラクル攻撃などの脆弱性を引き起こさない方法でエラーが処理されていることを検証する。
11.3.1 安全でないブロックモード（例：ECB）や脆弱なパディングスキーム（例：PKCS#1 v1.5）が使用されていないことを検証する。
11.3.3 暗号化されたデータが不正な改変から保護されていることを検証する。承認された認証付き暗号化方式を使用するか、承認された暗号化方式と承認されたMACアルゴリズムを組み合わせることが望ましい。
11.3.4 ノンス、初期化ベクトル、およびその他の使い捨て番号が、複数の暗号鍵とデータ要素のペアに対して再利用されていないことを検証する。生成方法は、使用されるアルゴリズムに適したものでなければならない。
11.4.2 パスワードが、承認された計算負荷の高い鍵導出関数（「パスワードハッシュ関数」とも呼ばれる）を使用して保存されており、パラメータ設定が現行のガイダンスに基づいて構成されていることを検証する。設定は、必要なセキュリティレベルに対してブルートフォース攻撃を十分に困難にするよう、セキュリティとパフォーマンスのバランスを取る必要がある。
11.5.1 推測不能であることが求められるすべての乱数および文字列が、暗号論的に安全な擬似乱数生成器（CSPRNG）を使用して生成され、少なくとも128ビットのエントロピーを持つことを検証する。UUIDはこの条件を満たさないことに注意する。
11.5.2 使用されている乱数生成メカニズムが、高負荷時でも安全に動作するように設計されていることを検証する。
12.1.1 TLS 1.2およびTLS 1.3など、TLSプロトコルの最新の推奨バージョンのみが有効化されていることを検証する。TLSプロトコルの最新バージョンが優先オプションでなければならない。
12.2.1 クライアントと外部向けのHTTPベースのサービス間のすべての接続にTLSが使用されており、安全でない通信や暗号化されていない通信にフォールバックしないことを検証する。
12.3.1 監視システム、管理ツール、リモートアクセスおよびSSH、ミドルウェア、データベース、メインフレーム、パートナーシステム、または外部APIを含む、アプリケーションとの間のすべての受信および送信接続にTLSなどの暗号化プロトコルが使用されていることを検証する。サーバーは、安全でないプロトコルや暗号化されていないプロトコルにフォールバックしてはならない。
12.3.4 内部サービス間のTLS接続が信頼できる証明書を使用していることを検証する。内部で生成された証明書または自己署名証明書が使用されている場合、利用側のサービスは特定の内部CAおよび特定の自己署名証明書のみを信頼するように構成されなければならない。
12.3.5 システム内部で通信するサービス（サービス間通信）が、各エンドポイントが検証されるようにするための強力な認証を使用していることを検証する。公開鍵基盤を使用し、リプレイ攻撃に耐性のあるメカニズムを用いたTLSクライアント認証などの強力な認証方式を採用して、本人性を確保しなければならない。マイクロサービスアーキテクチャの場合、証明書管理を簡素化しセキュリティを強化するために、サービスメッシュの使用を検討する。
13.2.1 APIやミドルウェア、データ層を含む、アプリケーションの標準的なユーザーセッションメカニズムをサポートしないバックエンドアプリケーションコンポーネント間の通信が認証されていることを検証する。認証には、個別のサービスアカウント、短期トークン、または証明書ベースの認証を使用しなければならず、パスワード、APIキー、または特権アクセスを持つ共有アカウントなどの固定的な資格情報を使用してはならない。
13.2.2 ローカルサービスやオペレーティングシステムサービス、API、ミドルウェア、データ層を含むバックエンドアプリケーションコンポーネント間の通信が、必要最小限の権限が割り当てられたアカウントで実行されていることを検証する。
13.2.5 Webサーバーまたはアプリケーションサーバーが、リクエストの送信先、またはデータやファイルの読み込み元として許可されたリソースまたはシステムの許可リストで設定されていることを検証する。
13.3.1 バックエンドのシークレットを安全に作成、保存、アクセス制御、および破棄するために、キーボールトなどのシークレット管理ソリューションが使用されていることを検証する。これらには、パスワード、鍵素材、データベースおよびサードパーティシステムとの統合、時間ベースのトークンの鍵およびシード、その他の内部シークレット、およびAPIキーが含まれる可能性がある。シークレットをアプリケーションのソースコードに含めたり、ビルド成果物に含めたりしてはならない。L3アプリケーションの場合、HSMなどのハードウェアに基づくソリューションを使用しなければならない。
13.3.3 すべての暗号操作が、鍵素材がセキュリティモジュールの外部に露出しないよう安全に管理および保護するために、隔離されたセキュリティモジュール（ボールトやハードウェアセキュリティモジュールなど）を使用して実行されていることを検証する。
13.4.2 本番環境のすべてのコンポーネントでデバッグモードが無効化されており、デバッグ機能の露出や情報漏洩が防止されていることを検証する。
13.4.3 明示的に意図されている場合を除き、Web サーバーがクライアントにディレクトリリストを公開していないことを検証します。
13.4.5 明示的に意図されている場合を除き、ドキュメント（内部 API 用など）および監視エンドポイントが公開されていないことを検証します。
13.4.6 アプリケーションがバックエンドコンポーネントの詳細なバージョン情報を公開していないことを検証します。
13.4.7 意図しない情報、設定、およびソースコードの漏えいを防ぐために、Web 層が特定のファイル拡張子を持つファイルのみを配信するよう構成されていることを検証します。
14.1.1 アプリケーションによって作成および処理されるすべての機密データが識別され、保護レベルに分類されていることを検証します。これには、Base64 文字列や JWT 内の平文ペイロードなど、エンコードされているだけで容易にデコードできるデータも含まれます。保護レベルは、アプリケーションが準拠する必要があるデータ保護およびプライバシーに関する規制や基準を考慮する必要があります。
14.1.2 すべての機密データの保護レベルに、文書化された一連の保護要件があることを検証します。これには、一般的な暗号化、整合性検証、保持、データのログ記録方法、ログ内の機密データに関するアクセス制御、データベースレベルの暗号化、使用するプライバシーおよびプライバシー強化技術、その他の機密性要件に関連する要件が含まれる必要があります（ただし、これらに限定されません）。
14.2.1 機密データが HTTP メッセージボディまたはヘッダーフィールドでのみサーバーに送信され、URL およびクエリ文字列に API キーやセッショントークンなどの機密情報が含まれていないことを検証します。
14.2.2 アプリケーションが、ロードバランサーやアプリケーションキャッシュなどのサーバーコンポーネントで機密データがキャッシュされることを防止しているか、または使用後にそのデータが安全に消去されることを保証していることを検証します。
14.3.3 ブラウザーストレージ（localStorage、sessionStorage、IndexedDB、Cookie など）に保存されたデータに、セッショントークンを除き、機密データが含まれていないことを検証します。
15.1.2 使用中のすべてのサードパーティライブラリについて、ソフトウェア部品表（SBOM）などのインベントリカタログが維持されており、さらに、コンポーネントが事前定義された信頼できる継続的に保守されているリポジトリから取得されていることも検証します。
15.2.4 サードパーティコンポーネントおよびそのすべての推移的依存関係が、内部所有か外部ソースかを問わず、想定されたリポジトリから取得されており、依存関係の混乱攻撃のリスクがないことを検証します。
15.3.3 アプリケーションが、コントローラーおよびアクションごとに許可されるフィールドを制限することで、マスアサインメント攻撃に対する保護対策を備えていることを検証します。例えば、そのアクションの一部として意図されていないフィールド値を挿入または更新できないようにします。
15.3.7 アプリケーションが HTTP パラメーター汚染攻撃に対する防御策を備えていること、特にアプリケーションフレームワークがリクエストパラメーターのソース（クエリ文字列、ボディパラメーター、Cookie、またはヘッダーフィールド）を区別しない場合にその対策が講じられていることを検証します。
15.4.1 マルチスレッドコード内の共有オブジェクト（キャッシュ、ファイル、または複数のスレッドからアクセスされるインメモリオブジェクトなど）が、スレッドセーフな型およびロックやセマフォなどの同期メカニズムを使用して安全にアクセスされ、競合状態やデータ破損が回避されていることを検証します。
15.4.2 リソースの状態（存在やアクセス許可など）に対するチェックと、それに依存するアクションが、チェック時と使用時の間の競合状態（TOCTOU）を防止するために、単一のアトミック操作として実行されていることを検証します。例えば、ファイルを開く前にその存在を確認する場合や、アクセスを許可する前にユーザーのアクセス権を検証する場合などです。
16.2.1 各ログエントリに、イベント発生時のタイムラインの詳細な調査を可能にする必要なメタデータ（いつ、どこで、誰が、何をなど）が含まれていることを検証します。
16.2.5 機密データをログに記録する際に、アプリケーションがデータの保護レベルに基づいてログ記録を実施していることを検証します。例えば、資格情報や支払い詳細など、特定のデータのログ記録が許可されない場合があります。セッショントークンなどのその他のデータは、全体または一部がハッシュ化またはマスク化された形でのみログに記録できます。
16.3.3 アプリケーションが、ドキュメントで定義されたセキュリティイベントをログに記録し、入力検証、ビジネスロジック、自動化防止などのセキュリティ制御を回避する試みもログに記録していることを検証します。
16.4.1 すべてのログコンポーネントが、ログインジェクションを防止するためにデータを適切にエンコードしていることを検証します。
16.4.2 ログが不正アクセスから保護されており、改ざんされないことを検証します。
16.5.1 予期しないエラーまたはセキュリティ上重要なエラーが発生した場合に、スタックトレース、クエリ、秘密鍵、トークンなどの機密性の高い内部システムデータが公開されないよう、利用者に汎用的なメッセージが返されることを検証します。
16.5.3 アプリケーションが、例外発生時を含め、適切かつ安全に処理を中止し、検証ロジックに起因するエラーがあるにもかかわらずトランザクションを処理してしまうようなフェイルオープン状態を防止していることを検証します。
16.5.4 すべての未処理の例外をキャッチする「最後の手段」のエラーハンドラーが定義されていることを検証します。これは、ログファイルに記録すべきエラーの詳細が失われることを回避するためと、エラーによってアプリケーションプロセス全体が停止し、可用性の喪失につながることがないようにするためです。