はじめに
GMOコネクトの永田です。
請負で関わっている2つのシステムで、Claude Code にソースを読ませて脆弱性を探す診断（ホワイトボックス診断）を回していました。緊急・高の指摘が出そろったところで並べてみると、どれもどこかで聞いたことのある話でした。
試しに OWASP ASVS 5.0 と突き合わせてみると、21件のうち6件が同じ1つの要件（8.2.2）に当てはまり、L1 の要件だけで12件が当てはまりました。ASVS は345項目あり、全部に目を通すのは大変です。実際に緊急・高になった要件から、要件定義でどのガイドラインのどこまでを指定しておけばよいかを考えた記録です。
先にまとめ
| 要件（ASVS 5.0） | 件数 | レベル |
|---|---|---|
| 8.2.2 データごとの認可（IDOR・BOLA） | 6 | L1 |
| 2.2.1 入力の値の検証 | 1 | L1 |
| 8.3.1 信頼できる層で認可する | 1 | L1 |
| 9.1.1 トークンの署名の検証 | 1 | L1 |
| 5.2.2・3.2.1・5.3.2 ファイルの種類・表示のされ方・パス | 2 | L1 |
| 14.2.1 URL に機微な情報を載せない | 1 | L1 |
| 8.2.3 項目ごとの認可 | 1 | L2 |
| 15.3.3 一括代入 | 1 | L2 |
| 2.4.1 呼び出しの回数・量の上限 | 1 | L2 |
| 6.6.3 コードによる認証の総当たり対策 | 1 | L2 |
| 6.8.1 複数の IdP での成りすまし | 1 | L2 |
| 13.3.1 秘密の管理 | 1 | L2 |
| ASVS の外（AWS の設定2件、古い API の残り1件） | 3 | 対象外 |
- AI の診断で見つかった緊急・高は、重複を除いて21件。そのうち6件が ASVS の 8.2.2 の1項目
- L1（70項目）の要件で21件中12件（57%）、L2 まで含めると18件（86%）
- 8.2.2 の6件のうち5件は、別の会社のデータに届くもの。テナントをまたぐ操作をはっきり求める 8.4.1 は L2 にある
- 要件定義で、準拠するガイドラインを決めておく。ASVS はせめて L1。複数の会社が使う、個人情報を扱うなど、セキュリティを重く見るサービスなら、項目が多くても L2 まで指定する
- AWS は Security Hub CSPM の FSBP の自動チェックを前提にする。今回の ASVS の外の3件に当たる検査は FSBP に見当たらなかったので、Well-Architected のセキュリティの柱などで補う
1. 何をどう数えたか
2つのシステムと、数えた指摘
どちらも AWS のサーバーレス（API Gateway と Lambda）と Amazon Cognito で作った、複数の会社が使う業務システムです。
数えたのは、診断で緊急度が「緊急」か「高」になった指摘です。緊急度は、深刻度と攻撃が成り立つ見込みの組み合わせで付けています。同じ原因の指摘は1件にまとめ、21件になりました。中・低の指摘は数えていません。AI が見落とした脆弱性も、当然この21件には入っていません。
診断のやり方と、ASVS を観点にしていないこと
診断は Claude Code のサブエージェントに任せました。システムを機能ごとの領域に分け、1つの領域を次の5体で見ています。
- 攻撃面（入口とデータの流れ）を洗い出す役: 1体
- 注入・認可・ロジックの観点ごとに候補を探す役: 3体
- 候補に反証を試み、残ったものだけを指摘にする検証役: 1体
観点は、社内で独自にメンテナンスしているチェックリストと、以前書いた Cognito の記事のチェック項目から作りました。ASVS は観点に使っていないので、「ASVS に書いてあった」は、緊急・高が出そろった後で ASVS 5.0 の原文と突き合わせた結果です。突き合わせの下書きは Claude に作らせ、要件の原文と指摘の本文で読み直しています。
ただし、Cognito の属性の件（2章の ASVS 8.3.1）は、Cognito の記事のチェック項目を観点に入れて探したものです。
ASVS 5.0 のレベル
ASVS 5.0.0 は 2025年5月に公開された版です。v5.0.0_release のタグの V1〜V17 の表を数えると、要件は345項目で、L1 が70、L2 が183、L3 が92でした。ASVS 自身は、L1 と L2 を次のように説明しています。
This level contains the minimum requirements to consider when securing an application and represents a critical starting point. This level contains around 20% of the ASVS requirements. The goal for this level is to have as few requirements as possible, to decrease the barrier to entry.
Most applications should be striving to achieve this level of security.
What is the ASVS?（OWASP ASVS 5.0.0）
L1 は、入り口の敷居を下げるために項目を絞った出発点です。L2 は、ほとんどのアプリが目指すべきレベルとされています。
当てはめで迷ったもの
1件に複数の要件が当てはまるときは、いちばん直接に書いている要件に数えました。迷ったのは次の3件です。
- 招待で役割の値を確かめない件: 一括代入（15.3.3、L2）にも読めますが、許された値の範囲を確かめていないことが核なので、2.2.1（L1）に数えました
- メールで送るコードの総当たりの件: パスワードの総当たり（6.3.1、L1）ではなく、コードの総当たり（6.6.3、L2）に数えました
- 画面でしか制限していない件: 8.3.1 にも当たりますが、他社の利用者に効くことが核なので、8.2.2 に数えました
例に使う架空のサービス
指摘は実在のシステムのものですが、説明の例はすべて架空のサービスにしました。
- 複数の会社が使う会議室の予約サービス
- 会社ごとに「管理者」と「一般の利用者」がいる
- 予約、メンバーの招待、議題の資料のアップロード、予約の通知メールがある
例は説明のためのもので、動かして確かめたものではありません。
2. L1 の要件に当てはまった12件
ASVS 8.2.2 データごとの認可（6件）
最も多かったのがこの要件です。
Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA).
IDOR・BOLA は、URL や本文の ID を書き換えるだけで、見てはいけないデータに届いてしまう問題です。会議室の予約サービスなら、次のような形です。
GET /reservations/1043
Authorization: Bearer <A社の利用者のトークン>
1043 が B社の予約でも、ログインさえしていれば返してしまう、という例です。6件は入口こそ違いますが、どれも「受け取った ID が、呼び出した人の会社・担当・役割で触ってよいものか」を確かめていませんでした。実際に出た形は次のとおりです。
- ID を変えるだけで、別の会社のデータを読める、書き換えられる
- 会社の管理者の役割なら、会社の確認を飛ばしてしまう
- 同じ会社の中でも、登録した人や公開の範囲を見ずに削除できる
- 画面では自社の利用者しか選べないが、API を直接呼ぶと他社の利用者にも効く
- 関連付けた別のデータの題名から、見られないデータの中身が漏れる
6件のうち5件は、別の会社のデータに届くものでした。確かめ方は単純で、入口ごとに「受け取る ID」と「所有者・所属・役割の確認があるか」を表にします。今回の診断でも、認可の担当にはこの表を全入口について作らせました。
ASVS 2.2.1 入力の値の検証（1件）
Verify that input is validated to enforce business or functional expectations for that input. This should either use positive validation against an allow list of values, patterns, and ranges, or be based on comparing the input to an expected structure and logical limits according to predefined rules. For L1, this can focus on input which is used to make specific business or security decisions. For L2 and up, this should apply to all input.
L1 では、業務やセキュリティの判断に使う入力から確かめればよい、としています。例はメンバーの招待です。
{ "email": "new-member@example.com", "role": "owner" }
画面は "member" と "admin" しか送らないのに、API が "owner" も受け取ってしまうと、管理者が自分より上の役割を作れます。役割は、まさに「セキュリティの判断に使う入力」です。
ASVS 8.3.1 信頼できる層で認可する（1件）
Verify that the application enforces authorization rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript.
緊急の1件がこれでした。Cognito のカスタム属性（例: custom:company_id）を認可に使っていて、その属性を利用者が自分で書き換えられる、という形です。利用者が書き換えられる値は、要件の言う "controls that an untrusted consumer could manipulate" に当たります。AWS の文書にも、この点が書かれています。
When you don't specify WriteAttributes for an app client, the app client has write access to all standard and custom attributes. Users can change the value of these attributes for themselves with UpdateUserAttributes. Your application or identity pool might make authorization decisions based on an attribute. In that case, remove the attribute from the WriteAttributes of every app client in your user pool.
Working with user attributes（Amazon Cognito）
Cognito の属性の書き込み権限は、以前の記事のチェックリストの(2)にまとめています。
ASVS 9.1.1 トークンの署名の検証（1件）
Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents.
Lambda が、ID トークンの中身（役割や会社）を、署名・発行者・期限を確かめずに使っていた件です。API Gateway のオーソライザで検証しているつもりでも、オーソライザを通らずに Lambda に届く経路があれば、作ったトークンがそのまま通ります。中身を使う側で検証するか、オーソライザが検証した値だけを使うようにします。期限の確認は、ASVS の同じ章の 9.2.1（L1）に書かれています。
ファイルの扱い（ASVS 5.2.2・3.2.1・5.3.2、2件）
1件目は、議題の資料のアップロードで、ファイルの種類も Content-Type も制限していなかった件です。HTML のファイルを上げると、資料のリンクを開いた人のブラウザで HTML として表示されてしまいます。
Verify that when the application accepts a file, either on its own or within an archive such as a zip file, it checks if the file extension matches an expected file extension and validates that the contents correspond to the type represented by the extension.（5.2.2 の冒頭）
Possible controls could include: not serving the content unless HTTP request header fields (such as Sec-Fetch-*) indicate it is the correct context, using the sandbox directive of the Content-Security-Policy header field or using the attachment disposition type in the Content-Disposition header field.（3.2.1 の後半）
拡張子を許可リストで絞り、署名付き URL を使うなら Content-Type と Content-Disposition も署名に含めて、上げる側が変えられないようにします。
2件目は、資料を取り出すときに、利用者が渡したキーに .. が含まれていても拒まなかった件です。
Verify that when the application creates file paths for file operations, instead of user-submitted filenames, it uses internally generated or trusted data, or if user-submitted filenames or file metadata must be used, strict validation and sanitization must be applied.（5.3.2 の冒頭）
キーはサーバー側で、予約の ID などの信頼できる値から組み立てます。
ASVS 14.2.1 URL に機微な情報を載せない（1件）
Verify that sensitive data is only sent to the server in the HTTP message body or header fields, and that the URL and query string do not contain sensitive information, such as an API key or session token.
外部のサービスにログインするとき、パスワードと client_secret を URL のクエリに載せ、その URL をログに出していた件です。ログを読める人なら、外部のサービスの資格情報を得られます。ログに出す側の要件（16.2.5）は L2 です。
3. L2 にしか無かった6件
次の6件は、当てはまる要件が L2 にしかありませんでした。どれも、システムの形によって重みが変わる要件でした。
| 要件（ASVS 5.0） | 件数 | 見ておきたいシステム |
|---|---|---|
| 8.2.3 項目ごとの認可（8.4.1 テナントをまたぐ操作も） | 1 | 複数の会社が使う |
| 15.3.3 一括代入 | 1 | 本文をそのまま保存先や外部のサービスに渡している |
| 2.4.1 呼び出しの回数・量の上限 | 1 | メールや SMS を送る、費用のかかる処理がある |
| 6.6.3 コードによる認証の総当たり対策 | 1 | メールや SMS で送るコードでログインさせる |
| 6.8.1 複数の IdP での成りすまし | 1 | SSO を受け入れる |
| 13.3.1 秘密の管理 | 1 | 外部のサービスの資格情報を持つ |
ASVS 8.2.3 項目ごとの認可と、8.4.1 テナントをまたぐ操作（1件）
Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA).
Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissions to interact.（8.4.1）
会社の情報を返す API が、他社から見てもよい会社名と一緒に、管理者個人の連絡先や会社の内部の設定まで返していた、という形です。そのデータを見てよいかと、その項目を見てよいかは別の確認です。BOPLA は、この項目の単位の確認が抜けている問題を指します。
2章の ASVS 8.2.2 の6件のうち5件も、別の会社のデータに届くものでした。どれも 8.2.2 に当てはまりますが、テナント（会社）をまたがないことをはっきり求めているのは L2 の 8.4.1 です。複数の会社が使うシステムなら、8.4.1 を設計の段階から要件に入れておくと、入口ごとに何を確かめるかが決まります。
ASVS 15.3.3 一括代入（1件）
Verify that the application has countermeasures to protect against mass assignment attacks by limiting allowed fields per controller and action, e.g., it is not possible to insert or update a field value when it was not intended to be part of that action.
予約の更新で、画面が送らない項目まで本文から受け取って保存していた、という形です。
{ "title": "定例会議", "status": "approved", "approved_by": "user-0001" }
画面は title しか送らないのに、status や approved_by を足すと、承認されたことにできてしまいます。入口ごとに受け取る項目を決め、それ以外は拒みます。
ASVS 2.4.1 呼び出しの回数・量の上限（1件）
Verify that anti-automation controls are in place to protect against excessive calls to application functions that could lead to data exfiltration, garbage-data creation, quota exhaustion, rate-limit breaches, denial-of-service, or overuse of costly resources.
予約の通知のメールや SMS を、回数の上限なく送り直せた件です。送るたびに費用がかかり、受け取る側には迷惑な通知になります。上限を入れた後の確認では、送った件数をロックせずに数えていたため、同時に呼ぶと上限を超えられることも分かりました。上限は、数え方まで含めて確かめる必要があります。
ASVS 6.6.3 コードによる認証の総当たり対策（1件）
Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using rate limiting. Consider also using a code with at least 64 bits of entropy.
ログインの2段目でメールに送るコードについて、アプリの API では誤答を数えていたのに、Cognito の API を直接呼ぶ経路では数えていなかった件です。パスワードを知っている人は、コードを何度でも試せました。Cognito の認証フローを絞る話は、先に挙げた Cognito の記事の(4)にまとめています。
ASVS 6.8.1 複数の IdP での成りすまし（1件）
Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). The standard mitigation would be for the application to register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IdP.
SSO で初めてログインした人を、IdP から届いた会社名が同じ会社に所属させていた、という形です。同じ名前を名乗れば、別の会社に入れてしまいます。要件のとおり、どの IdP から来たかと、その IdP の中の ID の組で見分けます。
ASVS 13.3.1 秘密の管理（1件）
Verify that a secrets management solution, such as a key vault, is used to securely create, store, control access to, and destroy backend secrets.（13.3.1 の冒頭）
外部のサービスの接続情報を設定ファイルにして S3 のバケットに置き、そのバケットが一部の IP アドレスの範囲から匿名で読めた件です。接続情報は、AWS Secrets Manager のような秘密の管理の仕組みに置きます。
4. ASVS の外の3件
ASVS はアプリケーションの要件なので、クラウドの設定や、使われていない API の後始末は直接には書いていません。残りの3件は、AWS の文書と OWASP API Security Top 10 に書いてありました。
Lambda の呼び出しの許可に、送信元の条件が無い（緊急）
Lambda の関数に API Gateway からの呼び出しを許すとき、送信元の API を絞っていなかった件です。ほかの AWS アカウントの API Gateway からも、この関数を呼べました。IAM の文書は、AWS のサービスに権限を与えるときに送信元の条件を付けるよう勧めています。
We recommend using aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, or aws:SourceOrgPaths in your resource policies wherever an AWS service principal is granted permission to access one of your resources.
The confused deputy problem（AWS IAM）
ASVS で近いのは、バックエンドの部品どうしの通信に認証と最小の権限を求める 13.2.1・13.2.2（L2）ですが、呼ばれる側が送信元を絞ることまでは書いていません。
踏み台のロールで、同じアカウントの全環境の秘密を読める（高）
本番と本番以外の環境が同じ AWS アカウントにあり、踏み台のロールから全環境の秘密の値を読めた件です。AWS のホワイトペーパーは、複数のアカウントを使う利点の1つに、本番と本番以外を分けられることを挙げています。
By using separate accounts for the non-production and production environments, by default, the resources and data that make up a workload environment are separated from other environments and workloads.
Benefits of using multiple AWS accounts（AWS ホワイトペーパー）
古い API と関数が残っていて、修正を回り込める（緊急）
作り直した後も、修正前の API Gateway と Lambda の関数が動いたまま残っていて、修正した側を通らずに呼べた件です。OWASP API Security Top 10 2023 の API9（Improper Inventory Management）が、この形を挙げています。
Threat agents usually get unauthorized access through old API versions or endpoints left running unpatched and using weaker security requirements.
API9:2023 Improper Inventory Management（OWASP API Security Top 10）
ASVS では 6.3.4（L2）が、認証の経路が複数あるなら文書に無い経路が無いことを求めています。今回の件は、認証以外の API も含めて修正前のものが丸ごと残っていたので、API9 に数えました。
5. 要件でガイドラインを決めて、設計と実装で確かめる
21件のうち18件は ASVS に、残りの3件も AWS の文書と OWASP API Security Top 10 に書いてありました。書いてあることなら、作り始める前に要件として決めておけます。ASVS 自身も、使い方の1つとして、調達のときに ASVS のレベルを指定することを挙げています。
The buyer can simply set a requirement that the software they wish to procure must be developed at ASVS level X, and request that the seller proves that the software satisfies ASVS level X.
What is the ASVS?（OWASP ASVS 5.0.0）
デジタル庁のセキュリティ・バイ・デザインガイドライン（DS-200）も、要件定義の工程の実施内容に、遵守すべき標準やリスク分析の結果に基づいてセキュリティ要件を決めることを挙げています。政府情報システム向けの参考文書で、遵守を強制するものではないとされています。
遵守すべきセキュリティ標準（セキュリティベースライン）やリスク分析結果等に基づく、システムとして満たすべきセキュリティ要件の定義（4.2 の「セキュリティ要件定義」の実施内容から）
DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（デジタル庁、2024年1月31日）
要件に書いたら、設計と実装の段階で、要件ごとに満たしているかを確かめます。なお、今回の21件は実装の後の診断で見つかったもので、設計の段階で確かめていれば防げたかどうかは試していません。
ASVS をどのレベルまで指定するか
「L1」とだけ指定すると、21件中9件は当てはまる要件がありません。L2 のどの要件が効くかはシステムの形で変わり、前もって選ぶのは難しいです。複数の会社が使う、個人情報を扱うなど、セキュリティを重く見るサービスなら、L1 と合わせて253項目と多くなっても、L2 まで指定する価値があります。ASVS 自身も、目指すレベルは、ASVS が決めず、組織がリスクを分析して、アプリの機微さと利用者の期待に応じて決めるとしています。
Rather than the ASVS prescriptively stating what level an application should be at, an organization should analyze its risks and decide what level it believes it should be at, depending on the sensitivity of the application and of course, the expectations of the application's users.
What is the ASVS?（OWASP ASVS 5.0.0）
ASVS 5.0 には、非公式ですが日本語訳もあります。要件を選ぶときは、原文と並べて読めます。
OWASP アプリケーションセキュリティ検証標準 5.0 日本語版（非公式、coky-t/owasp-asvs-ja）
ASVS の外の3件をどう指定するか
4章の3件（Lambda の呼び出しの許可、アカウントの分離、古い API の残り）は、ASVS の要件には当てはまりませんでした。AWS なら、Security Hub CSPM の AWS Foundational Security Best Practices（FSBP）で設定を自動でチェックする前提にしておくのが手軽です。
AWS Foundational Security Best Practices standard in Security Hub CSPM
ただし、FSBP の Lambda・API Gateway・アカウント・IAM の項目を見た範囲では、今回の3件に当たる検査はありませんでした。Lambda の関数のポリシーを見る Lambda.1 も、失敗とするのは公開されている場合と、S3 から呼ぶのに条件が無い場合です。
The control fails if public access is permitted. The control also fails if a Lambda function is invoked from Amazon S3, and the policy doesn't include a condition to limit public access, such as AWS:SourceAccount.
Security Hub CSPM controls for AWS Lambda
そこで、FSBP に加えて、次の3つも準拠するものとして要件に挙げておきます。
- AWS Well-Architected フレームワークのセキュリティの柱（アカウントの分離は SEC01-BP01 に書かれています）
- IAM の confused deputy の文書（AWS のサービスに権限を与えるときの送信元の条件。4章で引用）
- OWASP API Security Top 10（古い API の残りは API9。4章で引用）
SEC01-BP01 Separate workloads using accounts（AWS Well-Architected）
OWASP Top 10 API Security Risks – 2023
今度試したいこと
今回の診断の観点は、社内で独自にメンテナンスしているチェックリストから作りました。ただ、網羅できているかの確認と、これからのメンテナンスに課題があります。ASVS のようなガイドラインを観点にしても同じくらいの指摘を拾えるなら、その方が網羅の根拠も示しやすく、メンテナンスも外に任せられます。ASVS の L1 と L2 をそのまま観点として渡したら、今回の21件をどこまで拾えるかを試してみたいです。
まとめ
- AI の診断で見つかった緊急・高21件のうち、6件は ASVS 5.0 の 8.2.2（データごとの認可）の1項目に当てはまりました
- L1 の70項目に12件（57%）、L2 まで含めると18件（86%）が当てはまりました。残りの3件は AWS の設定と古い API の残りで、AWS の文書と OWASP API Security Top 10 に書いてありました
- 書いてあることなら、要件定義で準拠するガイドラインを決め、設計と実装の段階で確かめられます。ASVS は345項目ありますが、せめて L1 の70項目は要件に入れてほしいです
- ただし L1 の要件に当てはまらないものが21件中9件ありました。効く L2 の要件を前もって選ぶのは難しいので、複数の会社が使う、個人情報を扱うなど、セキュリティを重く見るサービスなら、項目が多くても L2 まで指定する価値があります
- AWS は Security Hub CSPM の FSBP で自動でチェックする前提にします。ただし今回の3件は、FSBP の文書を見た範囲では検査に当たるものがありませんでした。Well-Architected のセキュリティの柱、IAM の confused deputy の文書、OWASP API Security Top 10 で補います
最後に、GMOコネクトではサービス開発支援や技術支援をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。