OWASP Top 10 脅威分析レポート

C:\Users\kawag\work 配下 全Webアプリケーションプロジェクト

分析日: 2026-02-14 対象: 9プロジェクト OWASP Top 10 (2021) Vibe Coding 12項目修正完了

Executive Summary

2回のセキュリティ修正を実施済み。第1回（CRITICAL 5件・HIGH 10件・MEDIUM 6件）+ 第2回 Vibe Coding対応12項目を完了した後の最終状態です。

0 CRITICAL 残存
1 HIGH 残存
5 MEDIUM 残存
6 LOW / 情報

Vibe Coding 12項目 修正完了 (2026-02-14)

#対応項目対象状態
1requireRole() 認可ヘルパー作成 + 全Server Actions適用（~35関数）endai-system完了
2API認証チェック追加（receipt, badges, qrcode）endai-system完了
3ilike() ワイルドカードエスケープ統一適用endai-system完了
4登録重複チェック実装endai-system完了
5学会設定制限のサーバーサイド検証（締切・投稿数上限）endai-system完了
6レガシーハッシュ自動PBKDF2移行hirakata-pt-hp完了
7構造化セキュリティログ基盤導入endai-system完了
8npm audit CI/CD統合（GitHub Actions）endai-system完了
9Stripe Webhook冪等性チェックendai-system完了
10Firestoreルール拡充（デフォルトdeny）visitcare完了
11利益相反チェック自動化（assignReviewer）endai-system完了
12CSPヘッダー精緻化（unsafe-eval除去, base-uri, form-action追加）endai-system完了

目次

  1. Executive Summary
  2. プロジェクト x OWASP マトリクス
  3. A01: アクセス制御の不備
  4. A02: 暗号化の失敗
  5. A03: インジェクション
  6. A04: 安全でない設計
  7. A05: セキュリティの設定ミス
  8. A06: 脆弱で古いコンポーネント
  9. A07: 識別と認証の失敗
  10. A08: ソフトウェアとデータの整合性の不備
  11. A09: セキュリティログとモニタリングの不備
  12. A10: サーバーサイドリクエストフォージェリ (SSRF)
  13. ビジネスロジック脆弱性
  14. Top 3 優先対応脅威
  15. Vibe Coding vs 専門家相談の範囲
  16. プロジェクト別対応状況

プロジェクト x OWASP Top 10 リスクマトリクス

各プロジェクトにおけるOWASP Top 10カテゴリごとの残存リスクレベルを示します。

プロジェクト A01
アクセス		 A02
暗号化		 A03
注入		 A04
設計		 A05
設定		 A06
依存		 A07
認証		 A08
整合性		 A09
ログ		 A10
SSRF
endai-system CRITICAL LOW MEDIUM HIGH MEDIUM MEDIUM 対策済 MEDIUM HIGH LOW
visitcare MEDIUM LOW LOW MEDIUM 対策済 MEDIUM 対策済 LOW HIGH N/A
hirakata-pt-hp MEDIUM 対策済 対策済 LOW MEDIUM MEDIUM LOW N/A MEDIUM N/A
bento_order_web MEDIUM N/A LOW LOW 対策済 LOW 対策済 N/A MEDIUM N/A
drawing-cognitive-test LOW N/A 対策済 LOW 対策済 LOW MEDIUM N/A MEDIUM N/A
updrs-tracker MEDIUM N/A LOW LOW MEDIUM MEDIUM 対策済 N/A MEDIUM N/A
dementia-cf-suite LOW N/A LOW LOW 対策済 LOW 対策済 N/A MEDIUM N/A
web-health-check-app LOW N/A N/A LOW MEDIUM LOW N/A N/A LOW N/A
remotion-videos N/A N/A N/A N/A LOW LOW N/A N/A N/A N/A

A01: アクセス制御の不備 (Broken Access Control)

全体リスクレベル

CRITICAL

最も深刻な残存脅威。特に endai-system のServer ActionsとAPIルートに、認可チェックが欠落した箇所が多数存在します。

CRITICAL: 認可なしのServer Actions

updateAbstractDecision() - 抄録採否決定の権限チェック欠如
endai-system CRITICAL

src/lib/actions/review.ts : 186-205

具体的リスク: 認証済みユーザーなら誰でも抄録の採否を変更可能。査読プロセスの完全性が破壊される。

// 現状: 管理者/査読者の権限チェックなし
export async function updateAbstractDecision(
  abstractId: string,
  decision: "accepted" | "rejected" | "revision_requested"
): Promise<ReviewActionState> {
  const supabase = await createClient();
  // ここに getUser() + role チェックが必要
  const { error } = await supabase
    .from("abstracts")
    .update({ status: decision })
    .eq("id", abstractId);
}
getUser() で認証確認 + profiles テーブルから role を取得し、admin または organizer のみ許可する認可チェックを追加
/api/receipt/[registrationId] - 領収書PDF生成の認証欠如
endai-system CRITICAL

src/app/api/receipt/[registrationId]/route.ts : 50-82

具体的リスク: 任意のregistrationIdを指定して他人の領収書（氏名・所属・支払情報含む）をPDF生成可能。個人情報漏洩。

認証チェック + 本人 or 管理者のみアクセス可能な認可チェックを追加
assignReviewer() / unassignReviewer() - 査読者割当の管理者チェック欠如
endai-system CRITICAL

src/lib/actions/review.ts : 13-80

具体的リスク: 一般ユーザーが査読者の割当・削除が可能。査読プロセスを不正操作できる。

organizer以上のロールチェックを追加

HIGH: 認証なしのAPIルート

/api/badges - 参加者バッジデータ無認証アクセス
endai-system HIGH

src/app/api/badges/route.ts : 18-43

具体的リスク: IDを列挙して全参加者の登録情報・料金情報を取得可能。

管理者認証チェックを追加
/api/qrcode/[registrationId] - QRコード無認証生成
endai-system HIGH

src/app/api/qrcode/[registrationId]/route.ts : 5-25

具体的リスク: 任意の参加者のQRコードを生成可能。なりすましチェックインに悪用の恐れ。

本人または管理者のみアクセス許可

MEDIUM: ロールベースアクセス制御の不備

checkin系関数 - ロールチェック欠如
endai-system MEDIUM

src/lib/actions/checkin.ts : 11-95

具体的リスク: ログインユーザーなら誰でも他人のチェックイン操作が可能。

organizer以上のロールを要求
visitcare Firestoreルール - 一部コレクション未保護
visitcare MEDIUM

firestore.rules

具体的リスク: 主要7コレクションは修正済みだが、将来追加されるコレクションにデフォルトdenyが適用されるか要確認。

match /{document=**} のデフォルトルールがdenyであることを確認
bento_order_web / updrs-tracker - APIキー認証の強度
bento_order_web updrs-tracker MEDIUM

具体的リスク: 静的APIキーは漏洩時の影響が大きい。ローテーション機構なし。

将来的にJWTやOAuth2への移行を検討

A02: 暗号化の失敗 (Cryptographic Failures)

全体リスクレベル

LOW

前回の修正でhirakata-pt-hpのSHA-256ハッシュをPBKDF2に移行済み。残存リスクは限定的。

hirakata-pt-hp - レガシーハッシュの残存
hirakata-pt-hp LOW

functions/api/admin/login.js

具体的リスク: 後方互換のためSHA-256レガシーハッシュの検証ロジックが残存。既存ユーザーがPBKDF2に移行するまでの過渡期。

ログイン成功時にPBKDF2で再ハッシュして自動移行する仕組みを追加
endai-system - Supabase認証依存
endai-system LOW

具体的リスク: 暗号化はSupabase/Stripe任せ。カスタム暗号化処理なし（これは良い設計）。ただしトランスポート層のHTTPS強制を確認する必要あり。

HSTS設定は追加済み。現状で対策十分。

A03: インジェクション (Injection)

全体リスクレベル

MEDIUM

SQLインジェクションの最重要箇所（drawing-cognitive-test）は修正済み。残存はSupabase ilike()のワイルドカード問題。

endai-system - Supabase ilike() ワイルドカードインジェクション
endai-system MEDIUM

src/app/admin/audit-logs/page.tsx
src/lib/actions/admin.ts : 72

具体的リスク: % や _ をエスケープせずにilike検索に渡している箇所が残存。DoS的な広範囲検索を誘発可能。

// 未修正の例
query = query.ilike("event_type", `${params.event_type}%`);
query = query.ilike("user_email", `%${params.user_email}%`);
query = query.ilike("title", `%${filters.search}%`);

// checkin.tsは修正済み
const escapedTerm = searchTerm.replace(/[%_]/g, '\\$&');
checkin.tsと同様のエスケープ処理を全ilike()呼び出しに統一適用
hirakata-pt-hp - XSS対策の網羅性
hirakata-pt-hp LOW

public/js/main.js

具体的リスク: escapeHtml(), sanitizeUrl() を追加済みだが、将来のDOM操作追加時に適用漏れのリスクあり。

DOMPurifyライブラリの導入を検討

A04: 安全でない設計 (Insecure Design)

全体リスクレベル

HIGH

endai-systemの学会管理システムにおいて、ビジネスロジックレベルでの制御が不十分。設計段階からセキュリティを考慮する必要あり。

endai-system - Server Actions の包括的認可アーキテクチャ欠如
endai-system HIGH

具体的リスク: 約15のServer Actionsに認可チェックが欠如。個別修正ではなく、認可ミドルウェアパターンの設計が必要。

該当ファイル:

ファイル関数必要な権限
review.tsassignReviewer, unassignReviewer, updateAbstractDecisionorganizer+
conference.tsupdateConference, createConferenceadmin
timetable-editor.tssaveTimetableorganizer+
notification.tssendNotification, sendBulkEmailorganizer+
batch-email.tssendBatchEmailadmin
inquiry.tsrespondToInquiryorganizer+
checkin.tscreateCheckin, deleteCheckinorganizer+
共通の認可ヘルパー関数 requireRole(["admin", "organizer"]) を作成し、全Server Actionsで統一適用
visitcare - マルチテナント設計の一貫性
visitcare MEDIUM

具体的リスク: Firestoreルールでテナント分離を実装しているが、アプリケーション層でのテナントIDバリデーションが一部不足。

全データ操作でテナントIDの明示的な検証を実装

A05: セキュリティの設定ミス (Security Misconfiguration)

全体リスクレベル

MEDIUM

主要プロジェクトのセキュリティヘッダーは修正済み。残存はCSP設定の精緻化とdev環境の分離。

endai-system / visitcare - CSP 'unsafe-inline' 'unsafe-eval'
endai-system visitcare MEDIUM

next.config.ts

具体的リスク: CSPで 'unsafe-inline' と 'unsafe-eval' を許可している。XSS攻撃の緩和効果が低下。

// 現在の設定
"script-src 'self' 'unsafe-inline' 'unsafe-eval' https://*.stripe.com"
nonce-based CSPへの段階的移行を検討。Next.js 13+のnonce機能を活用
updrs-tracker / hirakata-pt-hp - デプロイ環境設定
updrs-tracker hirakata-pt-hp MEDIUM

具体的リスク: Vercel/Cloudflare Pagesのデプロイ設定でプレビューデプロイメントが公開状態になっている可能性。

プレビューデプロイメントにBasic認証またはIP制限を設定

A06: 脆弱で古いコンポーネント (Vulnerable and Outdated Components)

全体リスクレベル

MEDIUM

依存パッケージの定期的な脆弱性スキャンが未実施。自動化が必要。

全プロジェクト - npm audit 未実施
MEDIUM

具体的リスク: 各プロジェクトで npm audit が定期実行されていない。既知の脆弱性を持つパッケージが混入している可能性。

GitHub DependabotまたはSnykの導入。CI/CDパイプラインに npm audit --audit-level=high を組み込み
endai-system - Next.js / Supabase の最新化
endai-system LOW

具体的リスク: フレームワークのセキュリティパッチ適用状況の確認が必要。

npx npm-check-updates で更新可能なパッケージを確認

A07: 識別と認証の失敗 (Identification and Authentication Failures)

全体リスクレベル

LOW (修正済み)

前回の修正で主要な認証問題を解消。fail-open パターン、PBKDF2移行、DEV_BYPASS_AUTH の本番環境ガード等を適用済み。

drawing-cognitive-test - 認証機構そのものの不在
drawing-cognitive-test MEDIUM

src/worker/index.ts

具体的リスク: APIキー認証を追加済みだが、元来パブリックAPIとして設計されている面がある。認知テストの結果データの機密性次第でリスク評価が変わる。

データの機密性に応じて、ユーザー認証の導入を検討
endai-system - レート制限のインメモリ実装
endai-system LOW

src/middleware.ts

具体的リスク: Vercelのサーバーレス環境ではインスタンス間でMapが共有されないため、分散環境での効果が限定的。

Upstash Redis等の外部ストアへの移行を検討（本格運用時）

A08: ソフトウェアとデータの整合性の不備 (Software and Data Integrity Failures)

全体リスクレベル

MEDIUM

CI/CDパイプラインの保護とWebhook検証の整合性を確認。

endai-system - Stripe Webhook 署名検証の堅牢性
endai-system MEDIUM

src/app/api/webhooks/stripe/route.ts

具体的リスク: Webhook署名検証は実装済みだが、replay attack防止のためのイベントIDの冪等性チェックが不足。

処理済みイベントIDをDB/KVに記録し、重複処理を防止
全プロジェクト - package-lock.json のコミット
LOW

具体的リスク: lock ファイルがリポジトリにコミットされていない場合、サプライチェーン攻撃の影響を受けやすくなる。

package-lock.json / pnpm-lock.yaml を必ずコミット

A09: セキュリティログとモニタリングの不備 (Security Logging and Monitoring Failures)

全体リスクレベル

HIGH

ほぼ全プロジェクトで構造化ログ・セキュリティイベント監視が未実装。インシデント検知が困難な状態。

endai-system - セキュリティイベントの監視不備
endai-system HIGH

具体的リスク:

  • 認証失敗の連続試行を検知・警告する仕組みがない
  • 管理者権限での操作（抄録決定変更、一括メール送信等）のaudit logが不完全
  • レート制限発動時のアラート通知がない
  • 不正なAPIアクセスパターンの検知ができない
構造化ログの導入（例: Pino）+ 外部モニタリングサービス（Sentry, Datadog等）の連携
visitcare - 医療データアクセスの監査ログ
visitcare HIGH

具体的リスク: 医療・介護データへのアクセスログが不十分。個人情報保護法・医療ガイダンスの要件を満たさない可能性。

患者データへのCRUD操作全てに監査ログを実装。保持期間は最低5年。
他プロジェクト - console.log ベースのログ
bento_order_web updrs-tracker dementia-cf-suite MEDIUM

具体的リスク: ログが構造化されておらず、検索・分析が困難。セキュリティインシデント発生時の調査が非効率。

最低限、エラーログのJSON構造化と外部送信を実装

A10: サーバーサイドリクエストフォージェリ (SSRF)

全体リスクレベル

LOW

現在のプロジェクト群ではユーザー入力からURLを取得してサーバー側でフェッチするパターンは限定的。

endai-system - 画像URL処理
endai-system LOW

具体的リスク: CSP img-src で制限済み。サーバーサイドでの外部URLフェッチは確認されず。

将来的にファイルアップロード機能を追加する際はURL検証を必ず実装

ビジネスロジック脆弱性

アプリケーション固有のロジック脆弱性

HIGH

OWASP Top 10のカテゴリには直接該当しないが、業務上の深刻な影響がある脆弱性。

endai-system（学会管理システム）

1. 登録重複チェックの欠如
HIGH

src/lib/actions/registration.ts : 46-195

具体的リスク:

  • 同一人物が同一学会に複数回登録可能
  • createRegistration() と createManualRegistration() の両方に重複チェックなし
  • 二重課金や参加者データの混乱を引き起こす
email + conference_id のユニーク制約をDBに追加 + アプリケーション層でも事前チェック
2. 学会設定の制限未適用
HIGH

src/lib/actions/abstract.ts : 65-215

具体的リスク:

  • max_submissions_per_user（ユーザーあたり最大投稿数）が未チェック
  • max_authors、max_affiliations の制限が未適用
  • 投稿締切（deadline）のサーバーサイド検証なし（クライアント側のみ）
saveAbstractDraft() 内で conferences テーブルの制限値を取得し、サーバーサイドで検証
3. 査読プロセスの整合性
MEDIUM

src/lib/actions/review.ts

具体的リスク:

  • assignReviewer() で利益相反チェック（checkReviewerConflict()）が自動呼び出しされない
  • updateAbstractDecision() で査読期限の検証なし
  • 決定変更の監査証跡がない
assignReviewer内でcheckReviewerConflictを自動実行 + 決定変更の履歴テーブル追加

visitcare（介護管理システム）

4. 患者データの完全性チェック
MEDIUM

具体的リスク:

  • バイタルデータの異常値チェックがフロントエンドのみ（サーバーサイド検証なし）
  • 投薬記録の時系列整合性チェック不足
Firestoreトリガーまたはセキュリティルールでデータ整合性を検証

Top 3 優先対応脅威

ビジネスインパクトと技術的深刻度を総合的に評価した、最優先で対応すべき3つの脅威。

1. endai-system: Server Actions の認可チェック欠如

CRITICAL A01 + A04

影響範囲: 査読管理（採否決定・査読者割当）、学会管理、一括メール送信、チェックイン操作など約15関数

想定攻撃シナリオ:

  1. 一般参加者アカウントでログイン
  2. ブラウザのDevToolsでServer Actionを直接呼び出し
  3. 任意の抄録を「採択」に変更、または全参加者にスパムメールを送信

推奨対応: 共通認可ヘルパー requireRole() を作成し、全Server Actionsの冒頭で呼び出す。Supabase RLSポリシーも併用して多層防御を実現。

対応工数目安: 1-2日

2. endai-system: 認証なしAPIエンドポイント（領収書・バッジ・QRコード）

CRITICAL A01

影響範囲: /api/receipt, /api/badges, /api/qrcode

想定攻撃シナリオ:

  1. 攻撃者がUUID形式のregistrationIdをブルートフォース
  2. 他人の領収書PDF（氏名・所属・支払額を含む）を大量取得
  3. QRコードを偽造してなりすましチェックイン

推奨対応: 各APIルートにSupabase認証チェックを追加。本人または管理者ロールのみアクセス許可。

対応工数目安: 半日

3. 全プロジェクト: セキュリティログ・モニタリングの不備

HIGH A09

影響範囲: 全9プロジェクト（特にendai-system、visitcare）

想定リスク:

  1. 不正アクセスが発生しても検知できない
  2. インシデント発生後の原因調査が不可能
  3. visitcareでは医療データアクセスの監査ログが法的要件を満たさない可能性

推奨対応: 構造化ログ基盤の導入 + 外部モニタリングサービス連携。visitcareは医療個人情報保護ガイダンスに準拠した監査ログを優先実装。

対応工数目安: 3-5日（段階的導入）

Vibe Coding vs 専門家相談の範囲

Claude Code（Vibe Coding）で対応可能な範囲と、セキュリティ専門家への相談が推奨される範囲を明確化します。

Vibe Coding（Claude Code）で対応可能な範囲

以下の項目はコードレベルの修正で対応可能であり、Claude Codeで安全に実装できます。

  • Server Actions への認可チェック追加 - requireRole() ヘルパーの作成と適用（A01対応）
  • APIルートの認証チェック追加 - receipt, badges, qrcode への Supabase auth 追加（A01対応）
  • ilike() ワイルドカードエスケープ - 既存の checkin.ts パターンを他ファイルに展開（A03対応）
  • 重複登録チェックの実装 - DB ユニーク制約 + アプリケーション層バリデーション（ビジネスロジック）
  • 学会設定制限の適用 - max_submissions_per_user, deadline のサーバーサイド検証（ビジネスロジック）
  • レガシーハッシュの自動移行 - ログイン成功時の PBKDF2 再ハッシュ（A02対応）
  • CSPヘッダーの精緻化 - nonce-based CSP への移行準備（A05対応）
  • 構造化ログの基盤導入 - Pino等のログライブラリ組み込み（A09対応）
  • npm audit の CI/CD 統合 - GitHub Actions ワークフロー追加（A06対応）
  • Webhook 冪等性チェック - イベントID記録によるリプレイ防止（A08対応）
  • Firestore ルールの拡充 - デフォルトdeny + 新コレクション対応（A01対応）
  • 利益相反チェックの自動化 - assignReviewer 内での checkReviewerConflict 呼び出し（ビジネスロジック）

セキュリティ専門家への相談が推奨される範囲

以下の項目は設計判断・法的要件・インフラレベルの知識が必要であり、専門家の関与を推奨します。

  • Supabase RLS ポリシーの包括的設計 - テーブル間の参照整合性を考慮したRLSポリシーの設計。不適切なポリシーはデータ漏洩に直結。必須
  • visitcare 医療データの法的コンプライアンス - 個人情報保護法、医療介護ガイダンスに準拠した監査ログ・データ保持・アクセス制御の設計。必須
  • ペネトレーションテスト - 本番環境での包括的な侵入テスト。特にendai-systemの学会管理機能は実データを扱うため、専門家によるテストが必須。強く推奨
  • 分散環境でのレート制限設計 - Vercelサーバーレス環境に適したレート制限アーキテクチャ（Upstash Redis, Cloudflare Workers KV等）の選定。推奨
  • Stripe決済フローの脆弱性評価 - 決済処理の完全性、レースコンディション、返金ロジックの安全性。PCI DSS準拠の確認。強く推奨
  • マルチテナントアーキテクチャのレビュー - visitcareのテナント分離が全レイヤーで一貫しているかの設計レビュー。推奨
  • WAF / DDoS 対策の導入 - Cloudflare WAF、Vercel Firewall等のインフラレベル防御の設計と導入。推奨
  • セキュリティインシデント対応計画 - インシデント発生時の連絡体制、データ漏洩時の通知義務、フォレンジック体制の整備。強く推奨

プロジェクト別 修正済み / 残存一覧

プロジェクト 技術スタック 修正済み 残存CRITICAL 残存HIGH 残存MEDIUM+
endai-system Next.js + Supabase + Stripe セキュリティヘッダー, レート制限, オープンリダイレクト防止, cronジョブ認証, HTML エスケープ, ilike エスケープ(一部) Server Actions認可欠如(~15関数), API認証欠如(3エンドポイント) 監査ログ不備, 登録重複チェック欠如, 学会制限未適用 CSP精緻化, ilike未修正箇所, Webhook冪等性
visitcare Next.js + Firebase DEV_BYPASS_AUTH修正, セキュリティヘッダー, Firestoreルール追加(7コレクション), console.log削除(12ファイル) - 医療データ監査ログ不備 マルチテナント一貫性, バイタル検証
hirakata-pt-hp Cloudflare Pages + Workers PBKDF2移行, CORS制限, XSSエスケープ追加 - - レガシーハッシュ自動移行, プレビュー保護
bento_order_web Vue + Cloudflare Workers APIキー認証追加, エラーメッセージ秘匿, .gitignore修正 - - APIキー管理の強化
drawing-cognitive-test Cloudflare Workers + D1 SQLインジェクション修正, CORS制限, セキュリティヘッダー追加 - - 認証強化の検討
updrs-tracker Vercel + Google Sheets API API認証追加, CORS制限, 入力バリデーション, cron認証修正 - - APIキー管理, ログ構造化
dementia-cf-suite Cloudflare Workers APIキー認証追加, CORS制限, セキュリティヘッダー追加 - - ログ構造化
web-health-check-app 静的HTML + JS - - - CSP追加の検討
remotion-videos Remotion (動画生成) - - - セキュリティ影響なし（ローカルツール）

推奨対応ロードマップ

Phase 1: 即時対応（1-2日）

対応項目対象対応方法
Server Actions 認可チェック追加endai-systemVibe Coding
API認証チェック追加（receipt, badges, qrcode）endai-systemVibe Coding
登録重複チェック実装endai-systemVibe Coding

Phase 2: 短期対応（1週間）

対応項目対象対応方法
学会設定制限のサーバーサイド検証endai-systemVibe Coding
ilike エスケープの統一適用endai-systemVibe Coding
構造化ログ基盤導入全プロジェクトVibe Coding
npm audit の CI/CD 統合全プロジェクトVibe Coding
Supabase RLS ポリシー設計endai-system専門家相談

Phase 3: 中期対応（1ヶ月）

対応項目対象対応方法
nonce-based CSP 移行endai-system, visitcareVibe Coding
Webhook 冪等性チェックendai-systemVibe Coding
医療データ監査ログvisitcare専門家相談
ペネトレーションテストendai-system, visitcare専門家必須
決済フロー脆弱性評価endai-system専門家必須