OWASP ASVS 5.0で自分のアプリを採点する

世界水準編の最初の道具は、OWASP ASVS（Application Security Verification Standard、アプリケーションセキュリティ検証基準）です。Top 10が「気をつける項目」の一覧だったのに対し、ASVSは「合格か不合格かを判定できる要件」の一覧です。この章では、2025年5月に公開された5.0の構造を読み、実践編で確かめたことがASVSのどの要件に当たるかを対応づけ、自分のアプリをレベル1で採点します。

ASVSとは：Top 10との違い

応用編まで、私たちはOWASP Top 10:2025を「観点の一覧」として使ってきました。Top 10は意識づけの文書です。「アクセス制御の不備が最も多い」と教えてくれますが、「あなたのアプリは合格か」とは答えてくれません。

ASVSはそこを埋める文書です。原典の定義では、ASVSは「Webアプリケーションとサービスのためのセキュリティ要件を定義する」基準で、各要件は「検証可能で、合格か不合格かの判定で終わる」ものに限られます。要件はすべて「〜であることを検証する（Verify that）」という形で書かれ、推奨（should）ではなく必須（must）だけで構成されています。

経理の言葉に置き換えるなら、Top 10は「監査で指摘されやすい論点の一覧」、ASVSは「内部統制の評価項目書」です。評価項目書には項目ごとに番号が振られ、整備状況を「有効／不備」で記録します。ASVSの要件番号も同じ役割を果たします。要件の番号は「章.節.項目」の3つの数字で表され、たとえば 1.2.4 はV1（エンコーディングとサニタイズ）の第2節（インジェクション防止）の4番目の要件です。専門家との会話では、この番号がそのまま通じます。

原典は使い道として、設計の指針、安全なコーディングの基準、自動テストの設計、開発者教育、そして「調達の条件」を挙げています。発注者が「ASVSレベル2で開発すること」と契約に書き、受注者がそれを満たした証拠を出す、という使い方です。あなたが将来、業務システムの開発を外部に委ねる立場になったとき、この一行を仕様書に入れられるかどうかで、納品物の安全性は大きく変わります。

レベルL1／L2／L3

ASVSには3つの検証レベルがあります。5.0の原典は、レベルを「リスク低減と実装の手間を比べた優先度」で決めたと説明しています。

原典は例として、「限られた機微情報しか集めていない初期のスタートアップはL1から始めてよいが、銀行がオンラインバンキングでL3未満を顧客に説明するのは難しいだろう」と書いています。どのレベルを目指すかは、ASVSが決めるのではなく、「扱うデータの重さ」と「利用者の期待」から自分で決めるものです。第3章で扱った「見るだけ／入力やログインがある／他人のデータやお金を扱う」の3段階が、ここでそのまま使えます。

5.0ではL1が「達成しやすいように再設計」され、要件数が全体の約2割に絞られました。筆者が2026年10月時点のGitHub上の要件一覧から数えたところ、全345要件のうちL1は70要件でした。70項目なら、非エンジニアでも1日あれば一通り読めます。

5.0の章構成（V1〜V17）

ASVS 5.0は17の章に分かれています。次の表は、OWASPの公式リポジトリ（github.com/OWASP/ASVS の 5.0 ディレクトリ）にある章ファイル名から転記したものです。

原典は「機械同士のAPIならV3は関係ない」「OAuthやWebRTCを使っていなければ、その章は無視してよい」と明記しています。17章すべてを読む必要はありません。自分のアプリに存在する機能の章だけを選び、残りは「該当なし」と記録します。これは内部統制の評価で、自社に存在しない業務プロセスの項目を「対象外」とするのと同じ扱いです。

実践編の演習は、ASVSのどこに当たるか

実践編の第9〜13章でやったことは、知らないうちにASVSのL1要件の一部を検証していました。対応づけると、専門家に「ここまでは確認済みです」と番号で伝えられるようになります。

注意したいのは、ASVSには「文書化の要件」があることです。たとえば 6.1.1 は「総当たりやパスワードリスト攻撃への防御方法が、アプリの文書に定義されている」ことを求めています。8.1.1 は認可の規則の文書化です。原典は、文書化の要件は各章の最初の節に置かれ、必ず対応する実装の要件と対になっていると説明しています。第13章の演習で「持ち主への質問」に答えて作った業務ルールの一覧は、まさにこの文書に当たります。

5.0での主な変更点

4.0.3（2021年10月）から約3年半ぶり、2025年5月に公開された大改訂で、番号が全面的に振り直されました。4.0系の番号で書かれた古い記事や診断報告書は、5.0の番号とは一致しません。確認できた主な変更は次の通りです。

• CWE（共通脆弱性タイプ一覧）への直接の対応付けを廃止。原典は、分類だけのCWEがあることや、1要件を1つのCWEに対応づけにくいことを理由に挙げています。
• AI向けの要件は別規格AISVSへ。OWASP AISVS（Artificial Intelligence Security Verification Standard）1.0は2026年6月24日に公開され、12章構成で、ASVSと同じくL1〜L3の3段階です。AIを組み込んだアプリは、ASVSとAISVSの両方を見ることになります。
• パスワードの最小長は8文字、15文字以上を強く推奨（6.2.1）。あわせて、文字種の強制を禁じ（6.2.5）、貼り付けやパスワードマネージャーの利用を許可し（6.2.7）、秘密の質問を禁じています（6.4.2）。
• L1を達成しやすく再設計し、L3を大幅に拡張。L1は「参入の壁を下げる」ことを目的に絞り込まれました。

採点のしかた：4つの区分で記録する

採点は「満たす／満たさない」の二択にしないでください。非エンジニアが自力で判定できない要件は必ずあります。「分からない」を正直に残すほうが、点検としては価値があります。

採点表の列は「要件番号／要件の要旨／区分／確認日／確認方法／備考」の6つで十分です。第8章で作った点検ノートの下に追加してください。

このリポジトリを、OWASP ASVS 5.0 のレベル1の要件に照らして確認してください。

前提：
- あなたはこのコードを書いた人ではなく、独立した検証担当者として読んでください
- 推測で補わず、コードと設定ファイルから読み取れることだけを根拠にしてください
- 秘密情報の値そのものは絶対に出力しないでください
- 攻撃用の文字列やコードの例は出力しないでください
- 修正はまだしないでください。報告だけお願いします

手順：
1. まず、このアプリに存在する機能（ログイン、ファイルアップロード、OAuth、WebSocket、JWT など）を一覧にし、ASVS 5.0 の17章のうち「該当なし」にできる章を理由付きで挙げてください
2. 該当する章のレベル1要件を、要件番号（例：8.2.2）ごとに次の4区分で判定してください
   満たす／満たさない／該当なし／コードからは判断できない
3. 判定の根拠として、ファイル名と行番号、または設定箇所を示してください
4. 「コードからは判断できない」とした要件については、私が自分で確かめる方法（設定画面のどこを見るか、テスト用アカウントで何をするか）を書いてください
5. 文書化の要件（各章の第1節）については、どんな文書を用意すべきかを一言で書いてください

報告は「要件番号／要旨／判定／根拠／私が確かめる方法」の表にしてください。