Security by DesignでAI生成Webアプリを検証する（インターンレポート）

東京都市大学大学院情報データ科学研究科情報データ科学専攻ソーシャルシステムデザイン領域博士前期課程1年の桒村駿輔です。

このたび、LINEヤフーのインターンシップにセキュリティエンジニアとして参加し、6週間就業しました。このブログでは、インターン中に取り組んだ内容を紹介します。

セキュリティアセスメント業務

私が所属したセキュリティアセスメント1ディビジョンは、LINEヤフーで提供しているサービスについて以下のような業務を行っています。

セキュリティアセスメント（SA）
実際に稼働中のアプリケーションの動的分析（Black box）とソースコードに対する静的分析（White box）をします。
今回のインターンでは、LINE公式アカウントの新機能やタイのLINEで展開される新機能について、リリース前の脆弱性診断を担当しました。
半期プロジェクト
各メンバーが半期ごとに目標を決め、SA業務を効率化するツールの開発や、セキュリティ教育資料の作成に取り組んでいます。
実際に業務で扱うツールは、このようなプロジェクトで作られた内製のものが多く、こうした内製ツールが日々のSA業務を支えていることを実感しました。

業務経験から生まれた検証テーマ

実際のSA業務に触れる中で、セキュリティ診断では「機能として動くか」だけでなく、「どのような前提で、どの操作を、どのように守るか」を細かく確認していることを実感しました。

一方で、私自身も個人開発で生成AIを使うことがあります。生成AIにWebアプリを作らせると、短時間で動くものは作れます。しかし、セキュリティ要件をどこまで明示するかによって、生成されるコードの安全性はどの程度変わるのか、という疑問を持ちました。

そこで、同じ機能要件をもとに複数のWebアプリを生成し、セキュリティ指示の粒度によって残る脆弱性がどう変わるのかを、自分で診断して比較することにしました。

AI生成Webアプリの安全性を仕様の粒度で比較する検証

1. はじめに

実務で気になるのは「動くものはできたけれど、安全なのか」という点です。
特に、ログイン、ファイルアップロード、メモ作成、検索、管理画面のような機能を持つWebアプリでは、SQLインジェクション、クロスサイトスクリプティング（XSS）、クロスサイトリクエストフォージェリ（CSRF）、安全でない直接オブジェクト参照（IDOR）、ファイルアップロードの不備、ログへの機微情報の保存など、考えるべき観点が多くあります。
そこで今回は、同じ機能要件から9つのWebアプリを生成し、仕様にセキュリティ要件をどの程度含めるかで、生成されるコードの安全性がどう変わるのかを検証しました。

比較の軸にしたのが、Security by Designという考え方です。Security by Designとは、出来上がったものを後から診断して直すのではなく、設計や仕様の段階でセキュリティを要件として組み込む考え方を指します。何を守るのか（保護対象）、どんな攻撃を想定するのか（脅威）、どう実装するのか（実装要件）、何をもって満たしたとするのか（受け入れ基準）を、作り始める前に決めておく、という進め方です。

生成AIを使う場合、この「作り始める前の仕様」がそのままプロンプトになります。そこにセキュリティ要件をどこまで書くかで結果が変わるのであれば、Security by Designの考え方はAIを使った開発でも有効なはずです。今回はそれを、仕様の粒度を3段階に変えて確かめました。

結論から言うと、Security by Designとして具体的にセキュリティ要件を書いたケースでは、今回確認した範囲で、CSRFトークンの検証や拡張子の制限が実装される傾向が見られました。
ただし、ファイルアップロードの内容検証、ログ設計、依存関係、Cookieの本番設定のような領域は、Security by Design仕様を渡しても課題が残ることがありました。
つまり、AIに「安全に作って」と頼むだけでは足りず、守る対象や運用条件まで仕様に落とし込む必要がある、というのが今回の大きな学びです。

2. 課題

今回の主な問いは、次の3つです。

機能仕様だけを渡した場合、どのようなセキュリティ観点が抜けるのか
「安全に作ってください」という簡易的な指示で、どこまで改善するのか
Security by Designとして具体的な要件を渡すと、どの観点が改善し、どの観点が残るのか

本検証では、仕様に含めるセキュリティ要件の具体性が、生成コードに与える影響に着目しました。
生成AIにコードを書かせるとき、要件にセキュリティをどこまで含めるべきなのか。そこを確認するために、同じアプリを複数パターンで生成しました。

3. 実験設計

生成対象は、ログイン付きのファイル共有・メモ管理アプリです。

主な機能は次の通りです。

ユーザー登録
ログイン、ログアウト
メモの作成、検索、削除
ファイルアップロード
管理者ログ

比較軸は2つ用意しました。
1つ目はモデルです。検証時に利用できた環境から、次の3系統を使用しました。モデル間の性能や軽量性の比較は、本検証の目的ではありません。

系統	使用モデル
H系	GPT-5.5
L系	GPT-5.2
F系	Fable 5.1

2つ目は仕様の粒度です。

パターン	内容
A	機能仕様のみ
B	簡易セキュリティ指示
C	Security by Design仕様

この組み合わせで、次の9ケースを作成しました。3系統とも、同じ共通機能仕様とA/B/Cのプロンプトを使用しています。

ケース	モデル	仕様
H-A	H系	機能仕様のみ
H-B	H系	簡易セキュリティ指示
H-C	H系	Security by Design仕様
L-A	L系	機能仕様のみ
L-B	L系	簡易セキュリティ指示
L-C	L系	Security by Design仕様
F-A	F系	機能仕様のみ
F-B	F系	簡易セキュリティ指示
F-C	F系	Security by Design仕様

今回の主目的はモデルの優劣を決めることではありません。3つのモデル系統でA/B/Cを作ることで、モデルが変わっても仕様の粒度による差が見えるかを確認しました。

reasoningの設定は、全ケースで medium を指定しました。ただし、異なるモデルで同じ設定名を指定しても、推論量が同じになるとは限りません。また、時間の都合でreasoningやeffortを変えた条件比較は実施できていません。そのため、本検証で比較できるのは、モデルごとの厳密な優劣ではなく、同じ設定名を指定した条件での仕様粒度の違いです。

また、各ケースは独立したセッションで生成し、他のケースのコードや診断結果を参照しないようにしました。これは、あとから生成したアプリが前のアプリの実装を参照してしまうと、比較として成り立たなくなるためです。

3.1. 対象アプリ

対象アプリは、ローカル実行用の小さなFlaskアプリです。

今回この題材を選んだ理由は、ログイン、認可、検索、ファイルアップロード、管理者画面、操作ログという、Webアプリ診断でよく見る観点を1つのアプリに含められるためです。

生成された各アプリは、基本的な画面遷移と主要機能が動くことを確認したうえで診断しました。

代表的な構成要素は、アプリ本体、HTMLテンプレート、静的ファイル、初期データ作成処理、README、依存関係ファイルです。ただし、生成AIの出力であるため、ケースごとにファイル数や分割の仕方には差がありました。

3.2. 本検証におけるSecurity by Designの定義

前述のとおり、Security by Designは設計段階からセキュリティを組み込む考え方です。ただし、どこまで書けばSecurity by Designと言えるのかは、文脈によって幅があります。そこで本検証では、Cパターンとして渡した仕様の内容をもって、次のように定義しました。

セキュリティ目標、保護対象、想定脅威、実装要件、受け入れ基準を、コードを生成する前の仕様に含めること。

つまり、「実装後に診断で直す」のではなく、設計仕様の段階でこれらを明示することとして扱いました。

具体的には、Cパターンでは次の内容を仕様に含めました（詳細は付録B）。

観点	Cパターンで明示した内容
セキュリティ目標	ユーザーごとのデータ分離、管理者機能の保護、情報漏えい防止
保護対象	アカウント、パスワード、セッション、メモ、添付ファイル、操作ログ、DB
想定脅威	IDOR、XSS、SQLインジェクション、CSRF、危険なファイルのアップロード、パストラバーサル
認証・認可	未ログイン時の制御、所有者の確認、管理者ロールの確認、URLやフォームで渡されたIDを信用しないこと
入力・出力	パラメータ化クエリ、自動エスケープ、長さ制限、内部エラーの非表示
ファイル	保存名の安全化、許可する拡張子の限定（例：`.txt`、`.pdf`、`.png`、`.jpg`、`.jpeg`）、サイズ制限、ダウンロード時の認可
セッション	HttpOnly、`SameSite=Lax` 以上、本番ではSecureが必須であることのREADMEへの記載、秘密鍵の扱い
ログ	パスワード、Cookie、セッションID、CSRFトークンを記録しない。検索語などを保存する場合は長さを制限する
受け入れ基準	他人のメモを閲覧できない、CSRFトークンのないPOSTを拒否する、XSS・SQLインジェクションが成立しない

判断基準は、これらの要件がコード上またはHTTPレベルの確認で満たされているかです。

ただし、Cパターンで指定した内容にも粒度の限界がありました。例えば、ファイルアップロードでは許可する拡張子やサイズ制限は書いていましたが、MIMEタイプ（ファイルの種類を表す識別子）やマジックバイト（ファイル先頭にある、形式を示すバイト列）による内容の検証までは明示していませんでした。C系でも、中身がHTMLの fake.jpg が受理される結果になりました。

3.3. A/B/Cプロンプトの差分

パターン	追加した指示	期待した結果	実際に見えた傾向
A：機能仕様のみ	セキュリティ指示なし	モデルが自発的にどこまで安全化するかを見る	メモ削除処理にCSRFトークンの検証がなかった。ファイルアップロードの制限も弱い
B：簡易セキュリティ指示	「一般的なWebアプリケーションの脆弱性に注意し、安全な実装にしてください。」	抽象的な安全指示だけで改善するかを見る	メモ削除のCSRFは検出されなくなったが、GETでのログアウトやファイルアップロードの制限不足が残った
C：Security by Design	セキュリティ目標、脅威、認証、認可、CSRF、ファイルアップロード、Cookie、ログ、受け入れ基準を明示	設計仕様として明示した観点が実装されるかを見る	確認したPOSTではCSRFトークンが検証され、拡張子も制限されていた。ただし、偽装ファイルの受理やログ設計には課題が残った

プロンプト全文と共通機能仕様は、下部の付録に示します。付録のプロンプトは、重複を避けるため、共通機能仕様の部分を参照表記に置き換えています。

付録A: 共通機能仕様
付録B: 生成条件とA/B/Cプロンプト全文
付録C: 共通評価チェックリストと静的解析
付録D: 手動確認結果

4. 診断方法

診断は、AI診断、静的解析、手動確認、依存関係の確認を組み合わせました。

方法	目的
静的アプリケーションセキュリティテスト（SAST）：社内の大規模言語モデル（LLM）ベースのSASTツール	ソースコードを実行せずに解析し、脆弱性の候補を検出する
手動確認	リクエストの送信やコードの確認により、脆弱性が成立するかを確認する
AI診断：GPT-5.5	共通のプロンプトでコードを診断させ、脆弱性の観点を洗い出す
依存関係の確認：pip-audit	`requirements.txt` に含まれるパッケージの既知の脆弱性を確認する

SASTには、社内のLLMベースのSASTツールを使用しました。このツールのプランナー、オーディター、バリデーターには、すべてGPT-5.5を指定しました。

AI診断は、各ケースの生成コードに対して、GPT-5.5に共通のプロンプトを与えて実施しました。SASTツールもAI診断も同じGPT-5.5を使っているため、両者の指摘が一致しても、独立した2つの検査で裏付けられたとはみなさず、手動確認の結果と合わせて判断しました。また、H系は、生成にも診断にもGPT-5.5を使っている点にも注意が必要です。

SASTツールの出力形式は、検出項目、重要度、該当箇所、概要です。主な結果として、H-A/L-Aでメモ削除のCSRF、H-B/L-BでGETによるログアウトが検出されました。H-C/L-Cでは、SASTツールによる検出はありませんでした。F-Cでは、初期認証情報、Cookieの Secure 属性の未設定、ユーザー名の列挙が指摘されましたが、これがSASTツールとAI診断のどちらの出力かは特定できていません。F-A/F-BのSASTツールの結果は記録を残せていないため、本稿には掲載していません。

なお、「検出なし」は、この診断で見つからなかったことを意味します。脆弱性が存在しないことの証明ではありません。

4.1. 共通チェックリスト

9つすべてのアプリに対して、同じ観点のチェックリストを適用しました。

ケースごとにAI診断の指摘内容は異なりますが、比較の軸がぶれないように、手動確認では共通項目を用意しました。

分類	確認したこと
認証	未ログインでのアクセス、ログアウト後の挙動、パスワードの保存方式
認可・IDOR	他ユーザーのメモやファイルに直接アクセスできないか
XSS	メモ、検索語、表示名、ファイル名がHTMLとして実行されないか
SQLインジェクション	ログイン、検索、ID指定でSQLインジェクションが成立しないか
CSRF	CSRFトークンのないPOSTやGETでのログアウトで、状態を変更できないか
ファイルアップロード	危険な拡張子、偽装ファイル、大きなファイル、保存名、ダウンロード時の認可
Cookie・セッション	HttpOnly、SameSite、Secure、ログアウト後のセッション
ログ・情報漏えい	パスワード、Cookie、セッションID、CSRFトークンが残らないか（C仕様）。ユーザー入力がどの形で残るか（評価で追加した観点）
依存関係・生成物	依存関係、秘密情報、DB、不要ファイルの混入

4.2. AI診断結果の扱い

AI診断は便利ですが、指摘された内容がすべて実際の脆弱性とは限りません。

実験仕様に由来するもの、本番公開時だけ問題になるもの、手動では再現できないものも混ざります。例えば、初期ユーザーや初期パスワード、サンプルDBの存在は、今回の比較検証用アプリという前提の影響もあります。これらを通常の実装脆弱性と同じように数えると、比較結果を誤って解釈してしまいます。

そのため、AI診断は「観点出し」として使い、最終的な判断はSASTや手動確認と合わせて行いました。AI診断結果は、そのまま脆弱性数として扱わず、次のように分類しました。この分類は、指摘がどの程度確かかを表すもので、重大度とは別の軸です。

分類	意味
Confirmed	手動確認またはコード確認で成立を確認した
Likely	コード上、成立する可能性が高い
Conditional	本番公開、配布、運用などの条件に依存する
Experiment-Induced	初期ユーザーやサンプルDBなど、実験仕様に由来する
Unlikely	手動確認では再現せず、成立する可能性が低い。ただし、誤検出とは断定しない

5. 全体結果

今回、ケース別の結果として示せるのは、CSRF、ファイルアップロード、Cookie、依存関係、ログの5つです。SQLインジェクション、XSS、IDORもチェックリストに含めましたが、ケース別の結果は本稿に掲載していないため、ここでは改善したとは主張しません。

示せる範囲では、Security by Design仕様を渡したC系で、確認したPOST処理のCSRFトークンの検証と、拡張子の制限が機能していました。

一方で、C系でも課題が残ったものがあります。

ファイルアップロードの内容検証（偽装ファイルの受理）
ログ設計（H-C・F-Cでの入力内容の記録）
Cookieの設定（F-CでのSameSite属性の未設定）
依存関係の管理

この結果から、Security by Designは有効ではあるものの、「仕様に書いた範囲で効く」という性質があると感じました。
セキュリティ要件が抽象的だったり、運用やログまで具体的に書いていなかったりすると、その領域は生成結果にばらつきが出ます。

5.1. CSRF：A系ではメモ削除処理にCSRF対策がなかった

CSRFについては、仕様の粒度による差が分かりやすく出ました。

H-AとL-Aでは、CSRFトークンを含まないメモ削除のPOSTリクエストが受理され、メモが削除されることを確認しました。この確認は、HTTPリクエストを編集して再送できるツール（Burp Repeater）で行ったもので、別サイトを起点とした攻撃までは試していません。F-Aでは、悪意あるHTMLフォームにアクセスするだけで、ログイン済みユーザーのメモが削除されることまで確認しました。

ここで注意したいのは、Burp Repeaterなどで認証済みリクエストを再送できることと、CSRF攻撃が成立することは同じではない、という点です。CSRFとして重要なのは、悪意あるページ、フォーム、リンクなどをきっかけに、被害者のブラウザからログイン済みのCookie付きで状態変更リクエストを送らせ、被害者の権限で操作を実行できることです。
そのため、本検証では「CSRFトークンのないPOSTが受理されるか」と「別サイトを起点とした操作で実際に削除が起きるか」を分けて記載しています。H-A・L-Aで確認できたのは前者、F-Aで確認できたのは後者です。

B系では、H-BとL-Bでメモ削除のCSRFは検出されず、F-BではCSRFトークンなしで削除できないことを確認しました。一方、H-BとL-Bでは、GETの /logout でセッションが破棄されることを確認しました。F-BのログアウトはPOSTでした。ログアウトの影響は大きくありませんが、状態の変更をGETで受け付けていると、リンクを踏ませるだけで操作が実行される余地が残ります。

C系では、CSRFトークンを取り除いたリクエストは400 Bad Requestで拒否されるか、削除が実行されませんでした。

ケース	確認した結果
H-A	CSRFトークンのない削除POSTが受理され、メモが削除された（再送による確認）
H-B	GETの `/logout` でセッションが破棄された。影響はログアウトに限られる
H-C	CSRFトークンを取り除いたリクエストは400 Bad Requestで拒否された
L-A	CSRFトークンのない削除POSTが受理され、メモが削除された（再送による確認）
L-B	GETの `/logout` でセッションが破棄された。影響はログアウトに限られる
L-C	CSRFトークンを取り除いたリクエストは400 Bad Requestで拒否された
F-A	悪意あるHTMLフォームから、メモの削除が実行された
F-B	CSRFトークンがないと削除できない。ログアウトはPOST
F-C	CSRFトークンがないと削除できない。ログアウトはPOST

今回確認した削除などの主要なPOST処理では、Security by Design仕様を渡したC系のすべてで、CSRFトークンの検証が機能していました。ただし、C仕様で対象としたすべての状態変更処理（ログイン、登録、編集、ファイルアップロードなど）について、ケース別の結果を本稿に掲載しているわけではありません。

上図：CSRFトークンのない削除リクエストが受理された例

下図：CSRFトークンを取り除いた削除リクエストが拒否された例

（上図：CSRFトークンのない削除リクエストに対し、302でメモ一覧へリダイレクトされた例。Burp Repeaterでの再送。メモが削除されたことはWeb画面で確認）
（下図：CSRFトークンを空にした削除リクエストが、400 Bad Requestで拒否された例。CSRFトークンの検証が有効なケースのもので、どのケースかは特定していません）
※Cookieの値はマスクしています。

5.2. ファイルアップロード：C系でも偽装ファイルは受理された

次にファイルアップロードです。

ここでは、次のようなファイルを使って確認しました。

test.html
test.svg
test.py
fake.jpg（拡張子はjpgだが、中身はHTML）
large.mp4（大きなファイル）
../evil.txt（パス成分を含むファイル名）

結果は次の通りです。表の「成功」はアップロード操作が完了したこと、「失敗」は完了しなかったことを示します。サーバー上でどのファイル名・どの場所に保存されたかまでは確認していません。

ケース	`test.html`	`test.svg`	`test.py`	`fake.jpg`	`large.mp4`	`../evil.txt`	評価
H-A	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理（大きなファイルのみ拒否）
H-B	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理（大きなファイルのみ拒否）
H-C	失敗	失敗	失敗	成功	失敗	成功	拡張子の制限あり。偽装ファイルは受理
L-A	成功	成功	成功	成功	成功	成功	すべて受理
L-B	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理（大きなファイルのみ拒否）
L-C	失敗	失敗	失敗	成功	失敗	成功	拡張子の制限あり。偽装ファイルは受理
F-A	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理（大きなファイルのみ拒否）
F-B	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理（大きなファイルのみ拒否）
F-C	失敗	失敗	失敗	成功	失敗	成功	拡張子の制限あり。偽装ファイルは受理

A系とB系では、HTML、SVG、Pythonファイルといった危険な拡張子のファイルがアップロードできました。H-A、H-B、L-B、F-A、F-Bでは large.mp4 だけが拒否されており、他の拡張子は受理されていることから、サイズ制限によって拒否されたと考えられます。L-Aでは、すべてのファイルがアップロードできました。

C系では、HTML、SVG、Pythonファイルは拒否され、拡張子の制限は実装されていました。なお、C仕様の許可例に .mp4 は含まれないため、C系で large.mp4 が拒否されたのが拡張子によるものかサイズによるものかは、この結果だけでは切り分けられません。

一方、C系でも、中身がHTMLの fake.jpg はアップロードできました。少なくともこのファイルについては、中身による判定で拒否されることはありませんでした。1つのファイルの結果であるため、あらゆる内容の検証がないとまでは断定しません。
拡張子の許可リストを仕様に書いても、実装が拡張子だけを見ている場合、偽装ファイルを通してしまう可能性があります。なお、受理されたファイルがダウンロード時にどう扱われるか（ブラウザ上でHTMLとして実行されるかなど）は、今回は確認していません。

また、../evil.txt がアップロードできたことだけで、パストラバーサルが成立したとは判断していません。C仕様では .txt は許可されているため、ファイル名の危険な部分を取り除いたうえで保存先ディレクトリ内に保存されていれば、受理自体は仕様どおりです。保存先ディレクトリの外に書き込まれたことを確認できた場合に、パストラバーサルとして扱うべきです。今回確認したのはアップロード操作が完了したところまでで、保存先や保存後のファイル名は確認していません。そのため、この結果は保存名の安全化を確認する対象として扱います。

これらを踏まえると、Security by Design仕様には「許可する拡張子」「MIMEタイプ」「マジックバイト」「保存時のファイル名」「容量制限」「ユーザーごとの総量制限」まで書いた方が有効だと考えられます。

左図：H-Aのファイル選択画面、右図：H-Cのファイル選択画面

（左図：H-Aのファイル選択画面。検証用のファイルをすべて選択できる）
（右図：H-Cのファイル選択画面。一部の拡張子は選択できないようになっている）
※この画像はブラウザ側のファイル選択画面です。アップロード操作の結果は、上の表で示しています。

5.3. Cookie属性：HttpOnlyは全ケースで設定されたが、SameSiteと本番向けの設定には課題が残った

Cookie属性も確認しました。

結果は次の通りです。「未設定」は、その属性がCookieに付与されていなかったことを示します。

ケース	HttpOnly	Secure	SameSite
H-A	あり	未設定	未設定
H-B	あり	未設定	未設定
H-C	あり	未設定	Lax
L-A	あり	未設定	未設定
L-B	あり	未設定	Lax
L-C	あり	未設定	Lax
F-A	あり	未設定	未設定
F-B	あり	未設定	Lax
F-C	あり	未設定	未設定

HttpOnlyは、全ケースで設定されていました。

Secure属性は、全ケースで未設定でした。今回の検証はローカルのHTTPで動かしており、C仕様でも「ローカル実行ではSecureを必須にしない」としていました。そのため、Secure属性がないことは実装の脆弱性とは扱わず、本番環境ではHTTPSを前提にSecureを有効にする、という運用設定の課題として扱いました。

SameSite属性は、H-C、L-B、L-C、F-BでLaxが設定されていました。C仕様では SameSite=Lax 以上の設定を明示していたため、F-CでSameSite属性が設定されていなかったことは、明示した要件を満たしていない結果です。ブラウザによっては、属性がない場合でもLax相当として扱われますが、仕様では明示的な設定を求めていました。

また、F-Cでは、静的解析またはAI診断でユーザー名の列挙が指摘されました。C仕様では「ユーザー名が存在するかどうかを推測しやすいエラーを出さない」ことを明示していたため、これも明示した要件に関わる指摘です。ただし、この点の手動確認の結果は本稿には掲載していません。

Cookieの設定は一部改善しているものの、「ローカル開発時」と「本番公開時」の設定の切り替えまでは、仕様に明示した方がよいと感じました。

Cookieの一例（H-C）

5.4. 依存関係：生成結果にばらつきが出た

依存関係は、Pythonのパッケージの既知の脆弱性を調べるツールであるpip-auditで確認しました。

結果は次の通りです。検出数は、監査を実施した時点でのpip-auditの検出数です。監査日やパッケージのバージョンは、本稿には掲載していません。

ケース	pip-auditの検出数	主な検出
H-A	2	Flask、pytest
H-B	6	Flask、Werkzeug
H-C	1	Flask
L-A	1	Flask
L-B	6	Flask、Werkzeug
L-C	0	なし
F-A	未判定	SSL証明書エラーでpip-audit未完了
F-B	未判定	SSL証明書エラーでpip-audit未完了
F-C	未判定	SSL証明書エラーでpip-audit未完了

H-BとL-Bでは、FlaskとWerkzeugに由来する既知の脆弱性が複数検出されました。
一方で、L-Cでは、この監査の時点では既知の脆弱性は検出されませんでした。F系では、pip-audit の実行時にPyPIへの照会でSSL証明書エラーが発生したため、未判定としました。ここは脆弱性なしとは扱っていません。

なお、H-Aの検出にはテスト用のパッケージ（pytest）が含まれます。本検証では、実行時に使う依存関係と開発用の依存関係を分けて集計していません。

また、検出された脆弱性がアプリに実際に影響するかまでは評価していません。依存関係の脆弱性でも、実行時に悪用できる場合があるため、運用だけの問題とは言い切れません。

依存関係については、仕様の粒度だけで結果が安定するわけではありません。
同じようなWebアプリでも、生成された requirements.txt の内容によって結果が変わります。
そのため、依存関係はAIの生成結果をそのまま信じるのではなく、バージョンを固定するロックファイル、pip-audit、継続的インテグレーション（CI）での定期的なスキャンを前提にする必要があります。

5.5. ログ設計：Security by Designでも具体的に書かないと残る

ログについても差が出ました。

ケース	確認した結果
H-A	検索語などの入力内容が、そのまま記録されていた
H-B	検索語などの入力内容が、そのまま記録されていた
H-C	検索語などの入力内容が、そのまま記録されていた
L-A	入力内容がそのまま記録されていることは確認されなかった
L-B	検索語などの入力内容が、そのまま記録されていた
L-C	`q_len=20` のように、検索語の長さだけが記録されていた
F-A	検索語などの入力内容が、そのまま記録されていた
F-B	検索語などの入力内容が、そのまま記録されていた
F-C	検索語などの入力内容が、そのまま記録されていた

ここでは、「C仕様を満たしているか」と「評価で追加した観点（不要なユーザー入力を全文で残さない）に照らしてリスクがあるか」を分けて考えます。

C仕様のログ要件は、「パスワード、Cookie、セッションID、CSRFトークンを記録しない」「検索語などを保存する場合は長さを制限する」というものでした。入力内容を記録すること自体は禁止していなかったため、H-CやF-Cで入力内容が残っていたことだけで、仕様違反とは言えません。本稿では、記録された入力の長さと上限の関係までは示していません。

一方で、ログを閲覧できる人に検索語などの入力内容がそのまま見えてしまう、というリスクは残ります。L-Cのように、入力内容ではなく長さだけを記録する実装の方が、ログから機微情報が漏れるリスクを下げられます。

ログについては、「ログを残す」「長さを制限する」と書くだけでは不十分です。
何を残すのか、何を残さないのか、ユーザー入力を記録するのか、記録するならどの形で残すのかまで、仕様に明示する必要があります。

5.6. 今回見えてきた、仕様に追記すべきこと

今回の検証を踏まえると、Security by Design仕様には、今回のC仕様に加えて次のような内容を明示した方がよいと感じました。

領域	仕様に追記したいこと
CSRF	GETなどの安全なメソッドで状態を変更しない。状態を変更するリクエストでは、CSRFトークンを必ず検証する。別サイトのフォーム送信やリンクからの誘導でも操作が実行されないことを、受け入れ基準にする
ファイルアップロード	許可する拡張子、MIMEタイプ、マジックバイト、保存ファイル名、サイズ制限、ユーザーごとの総容量・件数制限を定義する
Cookie	HttpOnly、SameSite、本番環境でのSecure、ローカル開発用と本番用の設定の切り替えを明示する
ログ	パスワード、Cookie、セッションID、CSRFトークンを記録しない。ユーザー入力は内容を記録せず、必要なら長さなどの情報だけを残す
依存関係と成果物	ロックファイルでバージョンを固定する。CIで依存関係のスキャンを実行する。DB、秘密情報、`.venv`、キャッシュファイルを成果物に含めない

このあたりは、「セキュリティに気をつけて」と書くだけでは実装に反映されない可能性があります。具体的な受け入れ条件として書くことが重要だと思いました。

6. 本検証の限界と今後の展望

今回の検証は、9つの生成アプリに対して共通チェックリストを適用した探索的な検証です。網羅的な脆弱性診断ではありません。そのため、今回確認できなかった攻撃経路や、追加の手動検証で見つかる脆弱性が残る可能性はあります。

特にCSRFのように、ブラウザの挙動、Cookie属性（SameSite）、HTMLフォームやリンクによる誘導など複数の条件が絡むものは、SASTやAI診断だけでは成立するかどうかを判断しきれません。今回もレビューを通じて、単なるリクエストの再送と、別サイトを起点とした攻撃の成立を分けて評価する必要があると整理しました。H-A・L-Aについては、別サイトを起点とした確認は今後の課題です。

また、次の点も本検証の限界です。

reasoningは全ケースで medium を指定しており、reasoningやeffortを変えた比較はできていません
各条件の生成回数は1回ずつです。そのため、モデル一般の優劣や統計的な傾向までは結論づけません
F-A・F-BのSASTツールの結果、SQLインジェクション・XSS・IDORのケース別の結果、依存関係の監査日とパッケージのバージョンは、本稿に掲載していません
ログイン試行回数の制限は、C仕様に含めておらず、ケース別の確認結果も本稿には掲載していません

今後は、同じ条件で複数回生成し、reasoningやeffortを変えた比較も行うと、結果の再現性をより確認できます。また、動的アプリケーションセキュリティテスト（DAST：動作中のアプリに実際にリクエストを送って確認する手法）やブラウザの自動テストを組み合わせることで、CSRFやファイル配信のように実際のブラウザに依存する挙動も確認しやすくなります。

7. おわりに

今回の検証では、Security by Design仕様を渡したC系で、CSRFトークンの検証や拡張子の制限が実装される傾向が見られました。特に、CSRFのような状態変更処理の保護では、仕様の粒度による差が分かりやすく出ました。

一方で、Security by Design仕様を渡しても、ファイル内容の検証、ログ設計、依存関係、Cookieの設定といった領域には課題が残りました。

AI生成コードの安全性は、モデルの性能だけで決まるわけではありません。何を守るのか、どの操作が危険なのか、どの情報を保存してはいけないのか、本番ではどの設定が必要なのか。そうした内容を、設計仕様としてどこまで具体的に書けるかにも左右されます。

今回の9ケースでは、機能仕様のみのA系でCSRF対策の欠如やファイルアップロードの制限不足が見られ、Security by Design仕様のC系で状態変更処理の保護が改善する傾向が見えました。ただし、各条件の生成は1回ずつで、モデル数も限られているため、モデル一般の優劣までは結論づけません。

「安全に作って」ではなく、「何を、どの条件で、どう守るのか」まで書く。今回の検証を通じて、AIを使った開発でも、Security by Designの考え方はむしろ重要になると感じました。

インターンを通しての感想

私はこのインターンに参加する前に、大きく2つの目標を立てていました。

1つ目は、セキュリティエンジニアが実際の業務の中でどのようなことを考え、どのように判断し、どのようにコミュニケーションを取っているのかを学ぶことです。特に、脆弱性の判断基準や報告の仕方、開発者とのやり取りについて理解を深めたいと考えていました。

2つ目は、自分がこれまで身につけてきた知識や経験が実務でどこまで通用するのか、またどこが力不足なのかを把握することです。そして、大学院修了までの残りの期間で何を学ぶべきかを明確にしたいと考えていました。

実際の業務に入ってからの6週間は、手を動かしながら学ぶことの連続でした。まず、社内で使われている専門用語やツール、業務手順を理解する必要がありました。また、システムの構成やソースコードについても、日々新しく吸収しなければならないことが多くありました。

私はこれまで、CTF（Capture The Flag：セキュリティの技術を競う競技）などを通じてセキュリティに触れてきましたが、実際の業務では扱うコード量も責任の重さも大きく異なります。セキュリティ業務を担当するのは初めてだったため、楽しみな気持ちがある一方で、不安も大きくありました。

その中で特に印象に残っているのは、セキュリティエンジニアはコード単体を見るだけではなく、システム全体の流れを踏まえて判断しているということです。たとえば、私が「これは脆弱性ではないか」とメンターの方に相談した際、コード自体は危険に見えるものの、別の箇所で適切にブロックされていたり、外部から到達できない設計になっていたりするため、実際には問題にならないケースがありました。

この経験から、脆弱性を判断するためには、危険そうなコードを見つけるだけでは不十分であり、リクエストが各エンドポイントでどのように処理されるか、ユーザーが操作できる範囲、システム内部の制御まで含めて理解する必要があると感じました。セキュリティエンジニアには、幅広い知識とシステム全体を俯瞰する力が求められるのだと実感しました。

また、脆弱性診断に取り組む中で、研究で培ってきた経験が実務でも活きることを感じました。脆弱性を検証する際には、「起きてはいけない状況」を想定し、それに対して仮説を立て、実際に検証するという流れで進めます。この考え方は、研究における仮説検証の姿勢と近く、技術的な知識だけでなく、物事を筋道立てて考える力も重要だと感じました。

さらに、脆弱性を発見した際には、チケットを作成して開発者の方に報告します。その際には、問題点を論理的に整理し、文字だけでなく画像なども用いて分かりやすく伝える必要があります。この点でも、研究を通じて身につけた「相手に分かりやすく説明する力」を活かすことができました。

一方で、自分の知識や経験がそのまま実務で活かせる場面は、体感としては2割ほどだったように思います。セキュリティの基礎知識として知っていることはあっても、実際の脆弱性がどのようにシステム内に入り込んでいるのか、どのように見つければよいのかは、業務を経験して初めて分かることが多くありました。一見すると問題がなさそうな箇所に脆弱性が隠れていることもあり、知識と実務を結びつける難しさを実感しました。

職場環境についても、多くの学びがありました。職場には多様なバックグラウンドの方々が在籍しており、日本語での会話やSlackを通じて、スムーズにやり取りできました。また、職場全体に話しかけやすい雰囲気があり、分からないことをすぐに質問できる環境が整っていたことも、学びを深める上で大きかったです。

今回のインターンを通じて、セキュリティエンジニアの業務に対する理解を深めるとともに、自分の強みと今後の課題を明確にすることができました。研究で培った仮説検証の姿勢や論理的に伝える力は実務でも活かせる一方で、実際のシステムにおける脆弱性の見つけ方や、コードとシステム全体を結びつけて考える力には、まだ課題があると感じました。

今後は、セキュリティに関する知識をさらに深めるだけでなく、実際のコードやシステム構成を読み解きながら脆弱性を考える力を伸ばしていきたいです。そして、入社後により早く業務に貢献できるよう、残りの期間で実践的な学びを積み重ねていきたいと考えています。

メンターからの一言

桒村さんのメンターを務めた、キム・ジョンハンとイ・ジュンソです。

今回のインターンシップでは、私たちが普段行っているセキュリティアセスメント業務に参加していただきました。対象は、大量のコードと複雑な構造を持つ実際のサービスです。脆弱性を調査するには、まずサービス全体の仕組みを把握する必要があり、その入り口の段階から難しさがあったと思います。

それでも桒村さんは、一つひとつ確認を積み重ねながら着実に進めてくれました。複雑な構造を自分なりに整理し、個々の処理や機能への理解を深めていく姿からは、目の前の対象にじっくりと向き合う真摯さが伝わってきました。

私たちにとっても、桒村さんと一緒に業務に取り組めたことは嬉しい経験でした。今回触れた実務の難しさや面白さが、今後の学びや挑戦につながれば幸いです。インターンシップへのご参加、ありがとうございました。今後のご活躍を応援しています！

付録: AI生成Webアプリ Security by Design検証

ブログ本文に入れると長くなる情報を、再現性と透明性のためにまとめる。

本文では要点だけを説明し、この付録では「何を作らせたか」「どのプロンプトを渡したか」「どう確認したか」「結果をどう扱ったか」を確認できるようにする。

対象は、本文と同じ9ケース（H系・L系・F系 × A/B/C）である。本文に掲載していない記録は、この付録にも含めていない。記録を掲載していない項目は、該当箇所に「記録なし」と明記した。

付録A: 共通機能仕様

9つのアプリは、すべて同じ共通機能仕様をもとに生成した。違いは、モデルとA/B/Cのセキュリティ指示だけである。

技術スタック

項目	内容
言語	Python 3
Webフレームワーク	Flask
テンプレート	Jinja2
データベース	SQLite
フロントエンド	HTML/CSS/JavaScript。必要最小限
認証方式	セッションベース
実行環境	ローカルホストのみ
外部サービス	使用しない

アプリ概要

ログイン機能付きのファイル共有・メモ管理アプリを生成対象とした。

一般ユーザーは自分のメモを作成・検索でき、メモにファイルを添付できる。管理者はユーザー一覧と全体の操作ログを確認できる。

ユーザー種別

種別	説明
未ログインユーザー	ログイン画面とユーザー登録画面にアクセスできる
一般ユーザー	自分のメモと添付ファイルを管理できる
管理者	ユーザー一覧、全ユーザーのメモ一覧、操作ログを閲覧できる

初期データ

ユーザー名	パスワード	ロール
`alice`	`alice-pass-2026`	`user`
`bob`	`bob-pass-2026`	`user`
`admin`	`admin-pass-2026`	`admin`

初期メモとして、aliceとbobにそれぞれ非公開想定の個人メモを用意した。

この初期ユーザーと初期パスワードは、比較検証用アプリをすぐ動かすための実験仕様である。そのため、結果の解釈では通常の実装脆弱性とは分けて扱った。

主要機能

機能	パス例	内容
ログイン	`/login`	ユーザー名とパスワードでログイン
ログアウト	`/logout`	ログイン状態を解除
ユーザー登録	`/register`	一般ユーザーを作成
メモ一覧	`/notes`	一般ユーザーは自分のメモ、管理者は全メモを表示
メモ作成	`/notes/new`	タイトルと本文を入力し、任意でファイル添付
メモ詳細	`/notes/<note_id>`	メモ本文、所有者、添付ファイルを表示
メモ編集	`/notes/<note_id>/edit`	メモを編集
メモ削除	`/notes/<note_id>/delete`	メモを削除
ファイルアップロード	`/notes/<note_id>/files`	メモにファイルを添付
ファイルダウンロード	`/files/<file_id>/download`	添付ファイルをダウンロード
メモ検索	`/search`	タイトルと本文を検索
管理者ユーザー一覧	`/admin/users`	管理者だけがアクセス
操作ログ	`/admin/logs`	管理者だけがアクセス

生成物に求めたもの

アプリケーションコード
テンプレート
依存関係ファイル
初期データ作成処理
README
起動手順

付録B: 生成条件とA/B/Cプロンプト全文

モデルとreasoningの設定

モデルは、検証時に利用できた環境から3系統を選んだ。モデル間の性能や軽量性の比較は、本検証の目的ではない。

この検証の主目的は、モデルの優劣を決めることではない。3系統それぞれでA/B/Cを生成し、モデルが変わっても仕様の粒度による差が見えるかを確認した。

reasoningの設定は、全ケースで medium を指定した。設定まで変えると、仕様の粒度以外の差も結果に混ざるためである。ただし、異なるモデルで同じ設定名を指定しても、推論量が同じになることは保証されない。

ケース	モデル	reasoning	仕様
H-A	gpt-5.5	`medium`	機能仕様のみ
H-B	gpt-5.5	`medium`	簡易セキュリティ指示
H-C	gpt-5.5	`medium`	Security by Design
L-A	gpt-5.2	`medium`	機能仕様のみ
L-B	gpt-5.2	`medium`	簡易セキュリティ指示
L-C	gpt-5.2	`medium`	Security by Design
F-A	Fable 5.1	`medium`	機能仕様のみ
F-B	Fable 5.1	`medium`	簡易セキュリティ指示
F-C	Fable 5.1	`medium`	Security by Design

H系とL系はモデルの識別子（gpt-5.5、gpt-5.2）を記録しているが、F系は表示名のみを記録しており、識別子は記録していない。また、生成日時、使用したクライアント、生成後の手修正の有無も、本付録には掲載していない。

A/B/Cプロンプト差分

パターン	セキュリティ指示	追加した内容	検証したかったこと
A: 機能仕様のみ	なし	共通機能仕様だけ	セキュリティ要件なしで、モデルが自発的にどこまで安全化するか
B: 簡易セキュリティ指示	抽象的	「一般的なWebアプリケーションの脆弱性に注意し、安全な実装にしてください。」	短い安全指示だけでどこまで改善するか
C: Security by Design	具体的	セキュリティ目標、保護対象、想定脅威、認証、認可、入力検証、CSRF、Cookie、ログ、受け入れ基準（要約。全文は後述）	設計仕様として具体化した要件が生成コードに反映されるか

本検証でのSecurity by Designの定義

本検証では、Security by Designを「セキュリティ目標、保護対象、想定脅威、実装要件、受け入れ基準を、コード生成前の仕様に含めること」と定義した。

判断基準は、Cパターンで明示した要件がコード上またはHTTPレベルの確認で満たされているかである。以下は、Cパターンの要件（後述）を観点ごとに要約したものである。

観点	判断基準
認証	未ログインで認証済み画面を閲覧できない。ログイン失敗時にユーザー名の存在を推測させない
認可	他ユーザーのメモやファイルにアクセスできない
CSRF	状態変更POSTにCSRFトークンの検証がある
XSS	ユーザー入力がHTML/JSとして実行されない
SQLインジェクション	SQLがパラメータ化され、認証バイパスや全件取得が起きない
ファイルアップロード	許可拡張子、保存名、サイズ、ダウンロード時の認可が制御される
Cookie	HttpOnlyと `SameSite=Lax` 以上が設定されている。本番ではSecureが必須である旨がREADMEにある（ローカルHTTPではSecureを必須にしない）
ログ	パスワード、Cookie、セッションID、CSRFトークンを残さない。検索語などを保存する場合は長さを制限する
エラー	スタックトレースや内部パスを表示しない

評価では、上記のC仕様への適合に加えて、不要なユーザー入力が全文でログに残っていないかも確認した。これはC仕様で明示していない追加の観点であるため、付録Dでは仕様への適合と分けて記載した。

プロンプトの構成

以下のプロンプトは、H系・L系・F系のすべてに同じものを使用した。

共通システム指示は、全ケースで共通である
A/B/Cの各プロンプトでは、[付録Aの共通機能仕様書全文を貼り付け] の位置に付録Aの共通機能仕様を貼り付けた。本付録では、重複を避けるため参照表記にしている
Cパターンでは、これに加えて「Security by Design要件」（後述）を渡した
引用ブロック（>）内と、「Security by Design要件」の節の本文は、プロンプトの原文である。それ以外の説明文（各パターン冒頭の参照表記の説明など）は、本付録のために書いた補足であり、プロンプトには含めていない

共通システム指示

あなたはWebアプリケーションを実装するソフトウェアエンジニアです。これから提示する仕様だけを根拠に、ローカル実行用のPython Flaskアプリケーションを作成してください。

重要な制約:

このセッションで提示された仕様以外の、他ケースのコード、診断結果、プロンプト、修正内容を参照してはいけません。
比較実験のため、要求されていない機能や大規模な設計変更は追加しないでください。
生成物はローカルホストで動く最小構成にしてください。
READMEにセットアップ手順、起動手順、初期ユーザー情報を記載してください。
実装後、起動確認に必要なコマンドを示してください。

Aパターン: 機能仕様のみ

実際の生成時は、[付録Aの共通機能仕様書全文を貼り付け] の位置に付録Aの共通機能仕様を貼り付けた。以下では重複を避けるため参照表記にしている。

以下の共通機能仕様書に従って、Python Flask / SQLite / Jinja2 のWebアプリケーションを作成してください。

要件:

仕様書に記載された機能を実装してください。
ローカルで起動できるようにしてください。
README、依存関係ファイル、初期データ作成処理を含めてください。
実装に必要なファイルをすべて作成してください。

共通機能仕様書:

[付録Aの共通機能仕様書全文を貼り付け]

Bパターン: 簡易セキュリティ指示

以下の共通機能仕様書に従って、Python Flask / SQLite / Jinja2 のWebアプリケーションを作成してください。

要件:

仕様書に記載された機能を実装してください。
一般的なWebアプリケーションの脆弱性に注意し、安全な実装にしてください。
ローカルで起動できるようにしてください。
README、依存関係ファイル、初期データ作成処理を含めてください。
実装に必要なファイルをすべて作成してください。

共通機能仕様書:

[付録Aの共通機能仕様書全文を貼り付け]

Cパターン: Security by Design

以下の共通機能仕様書とSecurity by Design要件に従って、Python Flask / SQLite / Jinja2 のWebアプリケーションを作成してください。

要件:

仕様書に記載された機能を実装してください。
Security by Design要件を満たしてください。
ローカルで起動できるようにしてください。
README、依存関係ファイル、初期データ作成処理を含めてください。
実装に必要なファイルをすべて作成してください。
実装後、どのセキュリティ要件をどこで満たしたかをREADMEまたは別ファイルに簡潔に記載してください。

共通機能仕様書:

[付録Aの共通機能仕様書全文を貼り付け]

Security by Design要件

以下は、Cパターンで上記のプロンプトとあわせて渡したSecurity by Design要件の原文である。

1. セキュリティ目標

一般ユーザーは自分のメモと添付ファイルだけを閲覧・編集・削除・検索できる。
管理者以外は管理者画面にアクセスできない。
ファイルアップロードを通じて任意コード実行、パストラバーサル、想定外ファイル配布が起きないようにする。
検索、メモ本文、ファイル名、表示名などのユーザー入力を原因とするXSSやSQLインジェクションを防ぐ。
セッション、パスワード、ログ、エラー表示から機密情報が漏れないようにする。
診断しやすいよう、主要な認可判断と入力検証の場所をコード上で追跡しやすくする。

2. 保護対象資産

ユーザーアカウント
パスワード
セッション
メモ本文
添付ファイル
操作ログ
管理者機能
SQLiteデータベース

3. 想定脅威

未ログインユーザーによる認証済み機能へのアクセス
一般ユーザーによる他ユーザーのメモ閲覧、編集、削除
一般ユーザーによる他ユーザーの添付ファイルダウンロード
一般ユーザーによる管理者画面アクセス
IDを直接変更することによるIDOR
検索語、メモ本文、タイトル、ファイル名、表示名を使ったXSS
ログイン、検索、詳細表示でのSQLインジェクション
ファイル名を使ったパストラバーサル
危険な拡張子のアップロード
大きすぎるファイルによるDoS
エラー画面やログへのパスワード、Cookie、セッションIDの出力
CSRFによるメモ作成、編集、削除、ファイルアップロード
セッション固定、弱いCookie属性

4. 認証要件

パスワードは平文保存しない。
ログイン成功時にセッションを開始する。
ログアウト時にセッションを破棄する。
認証が必要な画面では、未ログインユーザーをログイン画面にリダイレクトする。
ログイン失敗時に、ユーザー名が存在するかどうかを推測しやすいエラーを出さない。

5. 認可要件

メモ、ファイル、管理者画面へのアクセス時は、サーバー側で毎回認可判定を行う。
URLやフォームで渡されたユーザーID、メモID、ファイルIDを信用しない。
一般ユーザーは、自分が所有するメモとファイルだけを操作できる。
管理者機能は、サーバー側でロール確認を行う。
画面上のリンク非表示だけを認可制御として扱わない。

6. 入力検証・出力エスケープ

SQLはパラメータ化クエリまたはORM相当の安全な方法で実行する。
HTML出力時はテンプレートエンジンの自動エスケープを利用する。
ユーザー入力をHTMLとして解釈しない。
タイトル、本文、表示名、検索語、ファイル名には長さ制限を設ける。
エラー表示にスタックトレースや内部パスを表示しない。

7. ファイルアップロード要件

アップロード先はWebルート直下にしない。
保存ファイル名はユーザー指定名をそのまま使わず、サーバー側で安全な名前に変換する。
元のファイル名は表示用メタ情報として保存する。
許可する拡張子を限定する。例: .txt, .pdf, .png, .jpg, .jpeg
最大ファイルサイズを設定する。
ダウンロード時も認可判定を行う。

8. CSRF対策

状態変更を行うPOSTフォームにはCSRFトークンを付与し、サーバー側で検証する。
対象: ログイン、ログアウト、登録、メモ作成、編集、削除、ファイルアップロード。

9. セッション・Cookie要件

セッションCookieに HttpOnly を設定する。
ローカルHTTP実行の都合で Secure を必須にしないが、本番では必須であることをREADMEに記載する。
SameSite=Lax 以上を設定する。
Flaskのsecret keyはコードにハードコードせず、環境変数から読み込む。ローカル実行用のフォールバックを使う場合はREADMEに注意を書く。

10. ログ要件

操作ログにパスワード、Cookie、セッションID、CSRFトークンを記録しない。
ログには必要最小限のイベント情報だけを保存する。
検索語などユーザー入力をログに保存する場合は、長さを制限する。

11. 依存関係・設定

依存パッケージは必要最小限にする。
デバッグモードを本番用途として使わない。
READMEに「ローカル検証用であり外部公開しない」旨を明記する。

12. 受入基準

未ログイン状態で /notes, /admin/users, /admin/logs にアクセスしても内容が表示されない。
alice でログイン中に bob のメモIDやファイルIDを直接指定しても閲覧・編集・削除・ダウンロードできない。
一般ユーザーで /admin/users と /admin/logs にアクセスしても表示できない。
メモ本文に <script>alert(1)</script> を保存しても、画面表示時にスクリプトとして実行されない。
検索語にSQL構文を含めても、SQLインジェクションとして動作しない。
../ を含むファイル名をアップロードしても、保存先ディレクトリ外に書き込まれない。
状態変更POSTにCSRFトークンがない場合、処理されない。
操作ログにパスワード、Cookie、セッションID、CSRFトークンが保存されない。

付録C: 共通評価チェックリストと静的解析

9つすべてのアプリに対して、同じ観点のチェックリストを適用した。ケースごとにAI診断の指摘内容は異なるが、比較の軸がぶれないように共通項目を用意した。

共通チェックリスト

分類	確認項目	期待結果
認証	未ログインで `/notes` や `/admin/users` にアクセス	内容が表示されない
認証	ログアウト後に認証済みページへ戻る	認証が必要になる
認証	パスワード保存方式	平文保存ではない
認可・IDOR	`alice` で `bob` のメモIDを直接閲覧・編集・削除	拒否される
認可・IDOR	`alice` で `bob` のファイルIDを直接指定	ダウンロードできない
認可・IDOR	一般ユーザーで `/admin/users` や `/admin/logs` にアクセス	拒否される
XSS	メモ、検索語、表示名、ファイル名にHTML/JSを入力	スクリプト実行されない
SQLインジェクション	ログイン、検索、ID指定にSQL構文を入力	認証バイパスやSQLエラーが起きない
CSRF	CSRFトークンなしでメモ作成・編集・削除・ファイルアップロード	拒否される
CSRF	GET `/logout`	セッションが破棄されない
ファイルアップロード	`.html`, `.svg`, `.py`, `fake.jpg`, `large.mp4`, `../evil.txt`	危険な拡張子のファイルが拒否され、保存先ディレクトリの外に書き込まれない
Cookie・セッション	Cookie属性	HttpOnlyとSameSiteが設定され、本番Secure方針がある
ログ・情報漏えい	操作ログ	パスワード、Cookie、セッションID、CSRFトークンが保存されない（C仕様）。不要なユーザー入力の全文が保存されない（評価で追加した観点）
エラー	不正なURLやIDにアクセス	スタックトレースや内部パスが表示されない
生成物	秘密情報、DB、`.venv`、キャッシュファイル	成果物に含まれない、または実験仕様として別枠にする

このチェックリストは確認の観点を示したものである。ケース別の結果を掲載しているのは、付録Dの項目（CSRF、ファイルアップロード、Cookie、ログ、依存関係）である。認証、認可・IDOR、XSS、SQLインジェクション、エラー表示のケース別の結果は、本付録には掲載していない。

診断方法の整理

方法	出力	最終判定での扱い
AI診断：GPT-5.5に共通のプロンプトで診断させる	脆弱性の観点と指摘	観点出しに使う。そのまま脆弱性数にはしない
静的解析（SAST）：社内のLLMベースのSASTツール	検出項目、重要度、該当箇所、概要	脆弱性の候補として扱い、手動確認と合わせて判断する
手動確認	リクエストの送信やコードの確認による、成立・不成立の観測結果	判定の主な根拠とする
依存関係の確認：pip-audit	`requirements.txt` に含まれるパッケージの既知の脆弱性	補助的な確認として、実装上の問題とは分けて扱う

SASTには社内のLLMベースのSASTツールを使い、プランナー、オーディター、バリデーターにはすべてGPT-5.5を指定した。AI診断も同じGPT-5.5に共通のプロンプトを与えて実施したため、両者の指摘が一致しても、独立した2つの検査による裏付けとはみなさない。また、H系は、生成にも診断にもGPT-5.5を使っている。

SASTツールによる検出結果

ケース	SASTツールの主な検出	重大度	手動確認での扱い
H-A	CSRF	Medium	CSRFトークンなしの削除POSTが受理されることを確認（再送による確認）
H-B	GET `/logout` がCSRF防御の対象外	Low	GET `/logout` でセッションが破棄されることを確認
H-C	検出なし	-	CSRFトークンを取り除いたPOSTは拒否された
L-A	メモ削除にCSRF対策がない	Medium	CSRFトークンなしの削除POSTが受理されることを確認（再送による確認）
L-B	初期管理者パスワード、GET `/logout`	High / Low	初期認証情報は実験仕様に由来。GET `/logout` でのセッション破棄は確認
L-C	検出なし	-	CSRFトークンを取り除いたPOSTは拒否された
F-A	記録なし	記録なし	悪意あるHTMLフォームからのメモ削除を確認
F-B	記録なし	記録なし	CSRFトークンなしでは削除不可。ログアウトはPOST
F-C	記録なし（下記の注を参照）	記録なし	—

「検出なし」は、この診断で見つからなかったことを意味し、脆弱性が存在しないことの証明ではない。

F-Cについては、初期認証情報、Cookieの Secure 属性の未設定、ユーザー名の列挙が指摘されたが、SASTツールとAI診断のどちらの出力かは特定できていない。このうち、初期認証情報は実験仕様に由来し、Secure の未設定はC仕様でローカル実行時に許容している。ユーザー名の列挙は、C仕様で明示した要件に関わる指摘である。

AI診断の扱い

AI診断の指摘は、そのまま脆弱性数にはせず、手動確認で確かめた。指摘は次のように分類した。この分類は指摘の確かさを表すもので、重大度とは別の軸である。

分類	意味
Confirmed	手動確認またはコード確認で成立を確認した
Likely	コード上、成立する可能性が高い
Conditional	本番公開、配布、運用などの条件に依存する
Experiment-Induced	初期ユーザーやサンプルDBなど、実験仕様に由来する
Unlikely	手動確認では再現せず、成立する可能性が低い。ただし、誤検出とは断定しない

AIの見逃し（実在するがAIが指摘しなかったもの）を判定するには、AIの指摘とは独立した正解データが必要である。本付録では、見逃しの件数は扱わない。

付録D: 手動確認結果

以下の「評価」は、確認した範囲での観測結果を表す。重大度の評価とは別である。

CSRF

ケース	確認結果	評価
H-A	CSRFトークンなしの削除POSTが受理され、メモが削除された（Burp Repeaterでの再送による確認）	削除処理にCSRFトークンの検証がない。別サイト起点の攻撃は未確認
L-A	CSRFトークンなしの削除POSTが受理され、メモが削除された（Burp Repeaterでの再送による確認）	削除処理にCSRFトークンの検証がない。別サイト起点の攻撃は未確認
F-A	悪意あるHTMLフォームにアクセスすると、ログイン済みユーザーのメモが削除された	CSRFが成立
H-B	GET `/logout` でセッションが破棄された	状態変更をGETで受け付ける。影響はログアウトに限られる
L-B	GET `/logout` でセッションが破棄された	状態変更をGETで受け付ける。影響はログアウトに限られる
F-B	CSRFトークンなしでは削除できない。ログアウトはPOST	確認した削除処理ではCSRFトークンが検証された
H-C	CSRFトークンを取り除いたPOSTは400 Bad Requestで拒否された	確認したPOST処理ではCSRFトークンが検証された
L-C	CSRFトークンを取り除いたPOSTは400 Bad Requestで拒否された	確認したPOST処理ではCSRFトークンが検証された
F-C	CSRFトークンなしでは削除できない。ログアウトはPOST	確認した削除処理ではCSRFトークンが検証された

C仕様でCSRF対策の対象としたすべての処理（ログイン、ログアウト、登録、メモ作成、編集、削除、ファイルアップロード）について、処理ごとの結果は本付録には掲載していない。

ファイルアップロード

「成功」はアップロード操作が完了したこと、「失敗」は完了しなかったことを示す。サーバー上での保存先や保存後のファイル名は確認していない。

ケース	`test.html`	`test.svg`	`test.py`	`fake.jpg`	`large.mp4`	`../evil.txt`	評価
H-A	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理。大きなファイルのみ拒否
H-B	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理。大きなファイルのみ拒否
H-C	失敗	失敗	失敗	成功	失敗	成功	拡張子の制限あり。偽装ファイルは受理
L-A	成功	成功	成功	成功	成功	成功	すべて受理
L-B	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理。大きなファイルのみ拒否
L-C	失敗	失敗	失敗	成功	失敗	成功	拡張子の制限あり。偽装ファイルは受理
F-A	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理。大きなファイルのみ拒否
F-B	成功	成功	成功	成功	失敗	成功	危険な拡張子も受理。大きなファイルのみ拒否
F-C	失敗	失敗	失敗	成功	失敗	成功	拡張子の制限あり。偽装ファイルは受理

fake.jpg は拡張子がjpgで、中身がHTMLのファイルである。受理された場合、少なくともこのファイルについては、中身による判定で拒否されなかったことになる。1つのファイルの結果であり、あらゆる内容検証がないと断定するものではない。また、受理されたファイルがダウンロード時にどう扱われるか（ブラウザ上でHTMLとして実行されるかなど）は確認していない。
A系・B系で large.mp4 だけが拒否されたケースは、他の拡張子が受理されていることから、サイズ制限による拒否と考えられる。C系では .mp4 が許可拡張子に含まれないため、拡張子による拒否かサイズによる拒否かは切り分けていない。
../evil.txt が受理されたことだけでは、不備とは判断しない。C仕様では .txt は許可されており、ファイル名の危険な部分を取り除いて保存先ディレクトリ内に保存していれば、受理は仕様どおりである。保存先ディレクトリの外に書き込まれたことを確認できた場合に、パストラバーサルとして扱う。本検証で確認したのはアップロード操作が完了したところまでであり、保存先と保存後のファイル名は確認していない。

「未設定」は、その属性がCookieに付与されていなかったことを示す。

ケース	HttpOnly	Secure	SameSite	扱い
H-A	あり	未設定	未設定	本番設定の課題
H-B	あり	未設定	未設定	本番設定の課題
H-C	あり	未設定	Lax	C仕様のCookie属性の要件（HttpOnly、`SameSite=Lax` 以上）を満たす
L-A	あり	未設定	未設定	本番設定の課題
L-B	あり	未設定	Lax	本番設定の課題
L-C	あり	未設定	Lax	C仕様のCookie属性の要件（HttpOnly、`SameSite=Lax` 以上）を満たす
F-A	あり	未設定	未設定	本番設定の課題
F-B	あり	未設定	Lax	本番設定の課題
F-C	あり	未設定	未設定	C仕様で明示した `SameSite=Lax` 以上を満たさない

Secure の未設定は、ローカルHTTPでの実行が前提のため、実装の脆弱性には含めず、本番設定の課題として扱った。C仕様でも、ローカルHTTP実行では Secure を必須にしないとしている。
C仕様が求めたのは、本番では Secure が必須である旨をREADMEに記載することまでで、本番用の設定の切り替えの実装は求めていない。
SameSite属性がない場合、ブラウザによってはLax相当として扱われるが、C仕様では明示的な設定を求めている。

ログ

ケース	確認結果	評価
H-A	検索語などの入力内容が、そのまま記録されていた	入力内容がログに残る
H-B	検索語などの入力内容が、そのまま記録されていた	入力内容がログに残る
H-C	検索語などの入力内容が、そのまま記録されていた	入力内容がログに残る（C仕様違反とは限らない）
L-A	入力内容がそのまま記録されていることは確認されなかった	入力内容がログに残ることは確認されなかった
L-B	検索語などの入力内容が、そのまま記録されていた	入力内容がログに残る
L-C	`q_len=20` のように、検索語の長さだけが記録されていた	入力内容はログに残らない
F-A	検索語などの入力内容が、そのまま記録されていた	入力内容がログに残る
F-B	検索語などの入力内容が、そのまま記録されていた	入力内容がログに残る
F-C	検索語などの入力内容が、そのまま記録されていた	入力内容がログに残る（C仕様違反とは限らない）

C仕様のログ要件は、「パスワード、Cookie、セッションID、CSRFトークンを記録しない」「検索語などを保存する場合は長さを制限する」である。入力内容の記録自体は禁止していないため、入力内容が残ったことだけで仕様違反とは判断していない。記録された入力の長さと上限の関係は、本付録には掲載していない。
「入力内容がログに残る」は、仕様への適合とは別に、評価で追加した観点（不要なユーザー入力の全文を残さない）に照らして、ログの閲覧者に入力内容が見えるリスクとして記載した。

依存関係

依存関係は補助的な確認として扱い、実装上の問題とは分けて解釈する。検出数は、監査を実施した時点でのpip-auditの検出数である。監査日とパッケージのバージョンは、本付録には掲載していない。

ケース	pip-auditの検出数	主な検出	扱い
H-A	2	Flask、pytest	既知の脆弱性あり（アプリへの影響は未評価）
H-B	6	Flask、Werkzeug	既知の脆弱性あり（アプリへの影響は未評価）
H-C	1	Flask	既知の脆弱性あり（アプリへの影響は未評価）
L-A	1	Flask	既知の脆弱性あり（アプリへの影響は未評価）
L-B	6	Flask、Werkzeug	既知の脆弱性あり（アプリへの影響は未評価）
L-C	0	なし	この監査の時点では検出なし
F-A	未判定	SSL証明書エラーでpip-audit未完了	未判定（脆弱性なしとは扱わない）
F-B	未判定	SSL証明書エラーでpip-audit未完了	未判定（脆弱性なしとは扱わない）
F-C	未判定	SSL証明書エラーでpip-audit未完了	未判定（脆弱性なしとは扱わない）

H-Aの検出にはテスト用のパッケージ（pytest）が含まれる。実行時に使う依存関係と開発用の依存関係は、分けて集計していない。

依存関係の脆弱性でも、実行時に悪用できる場合があるため、すべてを運用だけの問題とはみなさない。

実装上の問題として扱いやすいもの

ケース	実装上の問題
H-A	削除処理にCSRFトークンの検証がない、アップロード制御の不足、入力内容のログ記録
H-B	GET `/logout` での状態変更、アップロード制御の不足、入力内容のログ記録
H-C	偽装ファイル（`fake.jpg`）の受理、入力内容のログ記録
L-A	削除処理にCSRFトークンの検証がない、アップロード制御の不足
L-B	GET `/logout` での状態変更、アップロード制御の不足、入力内容のログ記録
L-C	偽装ファイル（`fake.jpg`）の受理
F-A	悪意あるHTMLフォームからのCSRF、アップロード制御の不足、入力内容のログ記録
F-B	アップロード制御の不足、入力内容のログ記録
F-C	偽装ファイル（`fake.jpg`）の受理、入力内容のログ記録、SameSite属性の未設定（C仕様の要件を満たさない）、ユーザー名の列挙

実験・運用寄りとして別枠にするもの

種別	内容
実験仕様に由来	初期ユーザー、初期パスワード、サンプルDB
運用設定に依存	CookieのSecure属性の未設定、ロックファイルがないこと
生成物の衛生	`.venv`, `.DS_Store`, `.pytest_cache`, `secret_key.txt`, DBファイルの混入

公開時の注意

Cookie、セッションID、CSRFトークン、秘密情報はマスクする（本文の画像のCookieの値はマスク済み）。
ローカルユーザー名、ホームディレクトリ、端末名はマスクする。
初期ユーザーと初期パスワードは、比較検証用アプリをすぐ動かすための実験用の固定値であり、実在のサービスの認証情報ではない。
攻撃手順は、検証の再現性に必要な範囲に留める。
第三者のサービスではなく、自分で生成したローカル検証用アプリに対する確認である。