OWASP ASVS 5.0 実践解説：V2 バリデーションとビジネスロジック（レベル1）を読み解く【セキュア開発技術Blog】

Securityチーム オーナーの松田です。

2025年5月に、OWASP ASVS の最新版である 5.0 がリリースされました。OWASP ASVS は、Webアプリケーションに対する一般的なセキュリティ要件をまとめたドキュメントです。非常に有用な一方で、約350の要件があり、すべてを読み込むには時間がかかります。さらに要件は抽象度が高く、実際のシステムに適用するには解釈が必要です。

本記事では、OWASP ASVS 5.0 の要件のうち、V2バリデーションとビジネスロジックのレベル1を解説します。

併せて、以下の記事も参考にしてください。

OWASP ASVSとは

OWASP ASVS（Application Security Verification Standard）は、アプリケーションセキュリティを検証するための項目を体系的にまとめた標準です。テスト時のチェックリストとして利用できるだけでなく、開発時に参照するセキュリティ要件集としても活用できます。これにより、セキュリティを「後付け」ではなく「設計段階から組み込む」ことができます。

全体像については、以下の記事をご覧ください。

ASVS の各要件には3段階のレベルがあり、検証の強度を表します。主にシステムが取り扱うデータの機密性に応じて、どのレベルの要件を採用するかを決めます。なお、文書および要件テキストでは L1 / L2 / L3 と表記されます。

各レベルの要件は、概ね以下のとおりです。

• レベル1：インターネットに公開されるすべてのアプリケーション向け（基本的なセキュリティ）
• レベル2：機密データを扱う業務アプリケーション向け（より強固なセキュリティ）
• レベル3：高度な攻撃対象となるシステムや重要インフラ向け（最高レベルのセキュリティ）

たとえば、限定的な機密データしか扱わないスタートアップ企業は、初期の目標としてレベル1を選ぶかもしれません。一方、銀行のオンラインバンキングアプリケーションでは、レベル3相当を目標にすべきでしょう。一般的な個人情報を扱うWebアプリケーションであれば、レベル2相当まで実装すべきと考えます。

本記事では、レベル1に絞って解説します。

V2 バリデーションとビジネスロジック

では、早速、V2のレベル1要件を順に見ていきます。原文は英語のため、日本語で要点を整理しながら解説します。

V2.1 バリデーションとビジネスロジックドキュメント

2.1.1

アプリケーションのドキュメントには、期待される構造に対するデータ項目の妥当性をチェックする方法についての入力バリデーションルールを定義している。これは、クレジットカード番号、電子メールアドレス、電話番号のような一般的なデータ形式のこともあれば、内部データ形式のこともある。

ドキュメントに関する内容です。

OWASP ASVS 5.0からドキュメントに関する要件が、明示的に定義されました。ドキュメントは、ビジネスロジックの制限、バリデーションルールを明確に定義して、開発者にアプリケーションに実装する必要があるものを明確に伝えるためのものです。必ず、書いてください。逆に、明確に書いてないと実装されません。

入力バリデーションルールは、以下のように検討します。

• まず、ホワイトリストで検証できるかどうかを検討します。

ホワイトリストとは、セレクトボックスやチェックボックスなどのような、予め決まったリストのことです。例えば、都道府県はホワイトリストで検証できます。ホワイトリストで検証できれば、受け付ける値の範囲を狭くできるため、有効な検証です。

ただ、ホワイトリストで検証できるケースは決して多くありません。名前やメールアドレスは、ホワイトリストを作ることはできないと思います。

2. 次に、ホワイトリストで検証できない場合、以下を検証します。

1. サイズ（文字数、数字の範囲、日付の範囲）
2. 許可される文字種（数字やアルファベットなど）
3. 構文、フォーマット（電話番号や日付、メールアドレスなど）
4. 業務要件として正しいか（開始日が終了日よりも前、購入数が正の数など）

特にサイズは非常に重要です。サイズの検証を怠ると、サービス拒否攻撃につながる可能性があります。例えば、大容量のファイルを多くアップロードされるとディスク容量に問題が発生するかもしれません。なので、入力バリデーションによって保存される前に、入力を拒否してください。

また、入力バリデーションは、どのデータに対して、実施すべきなのか？という質問をいただいたことがあります。入力バリデーションは、外部から入るデータには全て実施すべきです。ユーザが入力フォームで入力したデータに限らず、GETのパラメータやクエリパラメータも含めて、全て外部からシステムに入るデータは、全て実施してください。

ドキュメントには、これらの入力項目ごとの入力バリデーションルールを記載してください。もし、特別なルールなのであれば、そのルールになった理由も書いてあげると、後々わかりやすくなりそうです。

V2.2 入力バリデーション

2.2.1

入力はその入力に対するビジネスまたは機能上の期待を満たすことを検証されている。これは、許容される値、パターン、範囲のリストに対する肯定的なバリデーションを使用するか、あらかじめ定義されたルールに従って、期待される構造および論理的限界と入力との比較に基づく必要がある。L1 では、これは特定のビジネスまたはセキュリティ上の意思決定に使用される入力に焦点を当てることができる。L2 以上では、これはすべての入力に適用する必要がある。

2.1.1 で定義した入力バリデーションルールで検証しましょうという内容です。注目なのは、肯定的なバリデーションということです。

肯定的なバリデーションとは、「アルファベットと数字、記号のうち ¥ , . | が許可される」といったような許可形式のバリデーションを指します。

逆に、肯定的でないバリデーションは、「< > = ” ‘ 以外の文字を許可する」といった入力してはいけない文字でバリデーションすることです。入力してはいけない文字を定義するのは難しく、すり抜けてしまうことが多くに見受けられるため、必ず肯定的なバリデーションにしてください。

2.2.2

アプリケーションは信頼できるサービスレイヤで入力バリデーションを実行するように設計されている。クライアントサイドのバリデーションはユーザービリティを向上するため推奨されるが、セキュリティコントロールとしては依存してはいけない。

この要件は比較的わかりやすく、Webアプリケーションであれば、必ずサーバーサイドでバリデーションを実施するように求めています。クライアントサイドのバリデーションは、攻撃者によって迂回される可能性があります。例えば、APIを直接コールすることによって、迂回できます。

そのため、Webアプリケーションであれば、入力バリデーションは必ずサーバーサイドで実施してください。なお、信頼できるサービスレイヤとは、信頼境界の内部でバリデーションを強制できる層のことを指します。Webアプリケーションであれば、多くの場合サーバーサイドでデータを処理したり保管したりしますので、サーバーサイドがこれに該当します。

V2.3 ビジネスロジックのセキュリティ

2.3.1

アプリケーションは同じユーザのビジネスロジックフローを期待した正しい手順通り、省略せずに処理する。

この要件が言いたいのは、画面やAPIを正しい順序で踏まないと実行できないようにするということです。

例えば、ECサイトであれば、以下のような流れがあるはずです。

1. 商品をカートに入れる
2. 配送先を入力する
3. 支払い方法を選ぶ
4. 注文内容を確認する
5. 注文を確定する

このとき、攻撃者が 5. 注文を確定する API を直接呼び出して、配送先や支払い方法の入力を飛ばして、確定できてしまうと問題です。もしできた場合、支払い方法が存在しないまま確定できるかもしれません。あるいは、本来は確認画面で再計算される送料や割引額を、不正な値のまま確定できるかもしれません。

つまり、サーバー側で「このユーザは今どの段階にいるのか」「前の手順が完了しているか」を確認し、条件を満たしていないリクエストは拒否する必要があります。また、この要件には 同じユーザ という条件も含まれます。つまり、他のユーザの途中状態や、別のフローで作られた状態を流用して処理を進められないようにする必要があります。

実装上は、例えば以下のような対策になります。

1. サーバー側で処理ステップをセッションやDBに保持する
2. 次の処理を受け付ける前に、前段の処理完了を確認する
3. 価格、権限、申請状態などの重要な判定値は、クライアントから受け取った値をそのまま信用せず、サーバー側で再計算・再確認する

よくある失敗例としては、会員登録でメール認証を完了する前に本登録を許してしまう、パスワード再設定でトークン確認をせずに変更処理へ進めてしまう、管理者承認フローで承認前のデータを確定状態にできてしまう、といったものがあります。

要するに、ビジネス上「この順番でないと成立しない」処理は、その順番をアプリケーションが強制しなければなりません。画面の見た目で誘導するだけでは不十分で、サーバー側で手順の省略や順序違反を防ぐことが重要です。

まとめ

本記事では、V2 バリデーションとビジネスロジック のレベル1要件を解説しました。要件としては決して多くありませんでしたが、特に入力バリデーションは重要な内容です。

解釈には筆者の見解も含まれます。もし認識違いがあれば、ぜひフィードバックをお願いします。

【出典】

OWASP: Application Security Verification Standard
https://github.com/OWASP/ASVS

OWASP Application Security Verification Standard ja
https://github.com/owasp-ja/asvs-ja/