security-architecture-overview

セキュリティアーキテクチャの概要

プロジェクトのセキュリティプロファイル

プロジェクト: Secure Vibe Coding OS バージョン: 1.0 Next.js バージョン: 15.5.4 セキュリティ監査ステータス: 脆弱性 0 件 OWASP スコア: 90/100（Next.js アプリケーションの上位 10％）

このプロジェクトについて

Secure Vibe Coding OS は、後回しではなく、セキュリティを最優先事項として構築された、本番環境ですぐに使える SaaS スターターテンプレートです。基本的な認証を提供し、残りは開発者に任せる一般的な Next.js スターターとは異なり、このスターターには初日からエンタープライズグレードのセキュリティ制御が組み込まれています。

このアーキテクチャが存在する理由

Veracode の「2024 State of Software Security Report」によると、AI が生成したコードは 45％ の確率で安全でないパターンを選択します。一般的な SaaS スターターは、最低限のセキュリティガイダンスしか提供しないため、この問題をさらに悪化させます。その結果、開発者は安全でない基盤の上に機能を構築するよう AI にプロンプトを入力し、新しい機能が追加されるたびに潜在的な脆弱性が生まれます。

このアーキテクチャは、次の要素を提供することで、その悪循環を断ち切ります。

• 多層防御セキュリティ（複数のレイヤー）
• デフォルトで安全なパターン（セキュリティを緩和する場合は明示的な選択が必要）
• AI が使いやすいセキュリティユーティリティ（正しく使いやすい）
• OWASP スコア 90/100 を基準に設定（アプリケーションの上位 10％）

主なセキュリティ原則

1. 多層防御

すべてのリクエストは複数のセキュリティレイヤーを通過します。1 つが失敗しても、ほかのレイヤーが攻撃を検知します。

2. フェイルセキュア

エラーが発生した場合、システムはデフォルトでアクセスを拒否します。不正なアクセスを許可するよりも、エラーを表示するほうが安全です。

3. 最小権限

ユーザーとシステムには、必要最小限のアクセス権が与えられます。認証は本人確認を行い、認可は実行できる操作を制限します。

4. セキュリティは実装するものであり、前提とするものではない

ユーザーが「安全に使う」ことを前提にしません。すべてのユーティリティ、ミドルウェア、パターンにセキュリティを組み込んでいます。

5 層のセキュリティスタック

ビジネスロジックに到達する前に、すべてのリクエストは次のレイヤーを通過します。

User Browser
     │
     ▼
┌─────────────────────────────────────────────┐
│ Layer 0: Middleware (Security Headers)     │
│ • X-Frame-Options: DENY                     │
│ • Content-Security-Policy                   │
│ • HSTS (production only)                    │
│ • X-Content-Type-Options: nosniff           │
└──────────────┬──────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────┐
│ Layer 1: Rate Limiting                      │
│ • 5 requests per minute per IP              │
│ • Returns HTTP 429 when exceeded            │
│ • Prevents brute force & resource abuse     │
└──────────────┬──────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────┐
│ Layer 2: CSRF Protection                    │
│ • HMAC-SHA256 cryptographic signing         │
│ • Single-use tokens                         │
│ • Returns HTTP 403 if invalid               │
└──────────────┬──────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────┐
│ Layer 3: Input Validation                   │
│ • Zod schema validation                     │
│ • Automatic XSS sanitization                │
│ • Type-safe data transformation             │
│ • Returns HTTP 400 if invalid               │
└──────────────┬──────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────┐
│ Layer 4: Business Logic                     │
│ • Your handler code runs here               │
│ • Receives validated, sanitized data        │
│ • Clerk authentication checked in middleware│
└──────────────┬──────────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────────┐
│ Layer 5: Secure Error Handling              │
│ • Generic messages in production            │
│ • Detailed errors in development            │
│ • No information leakage                    │
└─────────────────────────────────────────────┘

これによって実現できること： 攻撃者がシステムを侵害するには、5 つすべてのレイヤーを同時に突破する必要があります。現在の攻撃手法では、事実上不可能です。

各セキュリティスキルを使う場面

API ルートの保護：

• csrf-protection skill：状態を変更する POST/PUT/DELETE エンドポイントを作成するとき
• rate-limiting skill：エンドポイントを悪用から保護するとき（フォーム、高負荷の処理など）
• input-validation skill：ユーザー入力を受け付けるとき（常に！）

アプリケーションセキュリティ：

• security-headers skill：ミドルウェアを設定するとき、または CSP/HSTS について理解する必要があるとき
• error-handling skill：API ルートでエラーレスポンスを実装するとき
• auth-security skill：Clerk を使って認証／認可を実装するとき

インテグレーション：

• payment-security skill：Clerk Billing 経由で Stripe の決済を実装するとき
• dependency-security skill：パッケージを追加するとき、またはセキュリティ監査を実行するとき

検証：

• security-testing skill：セキュリティ機能をテストするとき、またはデプロイ前チェックリストを確認するとき

アーキテクチャを決定した理由

なぜ多層セキュリティなのか？

単一障害点の問題： 従来の Web アプリケーションは、多くの場合、単一のセキュリティ対策に依存しています。その対策が機能しなかったり、回避されたりすると、システム全体が侵害されます。

実例： 2020 年の SolarWinds 攻撃では、侵害された単一のビルドサーバーが悪用されました。攻撃者はその対策を 1 つ突破しただけで、数千の組織にアクセスできました。多層防御を採用していれば、ほかの複数のレイヤーで侵入を検知できたはずです。

私たちのアプローチ： 堀、城壁、塔、内城を備えた中世の城のように、攻撃者はすべてのレイヤーを突破しなければなりません。各レイヤーが異なる種類の攻撃を防ぎます。

• ミドルウェア： リクエストがアプリケーションコードに到達する前に阻止します
• レート制限： 自動化された攻撃を阻止します
• CSRF： クロスオリジン攻撃を阻止します
• バリデーション： インジェクション攻撃を阻止します
• 認証／認可： 不正なアクセスを阻止します

完全なセキュリティスタックのパターン

完全にセキュアな API ルートは次のようになります。

// app/api/contact/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { withRateLimit } from '@/lib/withRateLimit';
import { withCsrf } from '@/lib/withCsrf';
import { validateRequest } from '@/lib/validateRequest';
import { contactFormSchema } from '@/lib/validation';
import { handleApiError } from '@/lib/errorHandler';

async function contactHandler(request: NextRequest) {
  try {
    const body = await request.json();

    // Layer 3: Input validation
    const validation = validateRequest(contactFormSchema, body);
    if (!validation.success) {
      return validation.response;
    }

    const { name, email, subject, message } = validation.data;

    // Safe to process - all security layers passed
    await sendEmail({ to: '[email protected]', from: email, subject, message });

    return NextResponse.json({ success: true });

  } catch (error) {
    // Layer 5: Secure error handling
    return handleApiError(error, 'contact-form');
  }
}

// Layers 1-2: Apply security middlewares
export const POST = withRateLimit(withCsrf(contactHandler));

export const config = {
  runtime: 'nodejs', // Required for crypto operations
};

環境ごとのセキュリティ

開発（緩和）

• ✅ 詳細なエラーメッセージ（完全なスタックトレース）
• ✅ 詳細なログ記録
• ✅ HTTP を許可（localhost）
• ✅ 開発用キー

本番環境（最大限の保護）

• ✅ 汎用的なエラーメッセージのみ
• ✅ 最小限のログ記録（PII なし）
• ✅ HTTPS を強制（HSTS）
• ✅ 本番環境用キー

自動検出： コードは process.env.NODE_ENV === 'production' を検出し、セキュリティ設定を自動的に調整します。

技術スタックのセキュリティコンポーネント

認証：Clerk

• SOC 2 認証済み
• パスワードのハッシュ化、セッション、MFA、OAuth を処理
• カスタム実装と比べて認証の脆弱性を 73% 削減
• スキル： auth-security

決済：Clerk Billing + Stripe

• カードデータには一切触れない
• PCI-DSS 準拠（Stripe 経由）
• Webhook 署名の検証
• スキル： payment-security

データベース：Convex

• 型安全なクエリ
• ctx.auth.userId によるユーザー単位のデータ管理
• ミューテーションで追加の検証を実施

フレームワーク：Next.js 15.5.4

• 最新のセキュリティパッチ
• グローバルなセキュリティ制御のためのミドルウェア
• より適切なセキュリティ境界を実現する App Router

クイックリファレンス：セキュリティチェックリスト

新しい API ルートを作成するときは、次の点を確認してください。

• ルートが悪用される可能性がある場合は withRateLimit() を適用した
• POST/PUT/DELETE には withCsrf() を適用した
• lib/validation.ts の Zod スキーマで入力を検証した
• catch ブロックで handleApiError() を使用した
• Clerk の await auth() で認証を確認した
• ユーザー固有のリソースにアクセスする場合は認可を確認した
• 適切な HTTP ステータスコード（200、400、401、403、404、429、500）を使用した
• 機密データ（パスワード、トークン、PII）をログに記録していない
• 暗号化処理のため、設定に runtime: 'nodejs' を設定した
• コミット前にエンドポイントをテストした

よく使うパターン - コピー＆ペースト用テンプレート

テンプレート 1：シンプルな保護付きエンドポイント（CSRF なし）

import { NextRequest, NextResponse } from 'next/server';
import { withRateLimit } from '@/lib/withRateLimit';
import { handleApiError, handleUnauthorizedError } from '@/lib/errorHandler';
import { auth } from '@clerk/nextjs/server';

async function handler(request: NextRequest) {
  try {
    const { userId } = await auth();
    if (!userId) return handleUnauthorizedError();

    // Your logic here

    return NextResponse.json({ success: true });
  } catch (error) {
    return handleApiError(error, 'route-name');
  }
}

export const GET = withRateLimit(handler);
export const config = { runtime: 'nodejs' };

テンプレート 2：完全な保護を備えたフォーム送信

import { NextRequest, NextResponse } from 'next/server';
import { withRateLimit } from '@/lib/withRateLimit';
import { withCsrf } from '@/lib/withCsrf';
import { validateRequest } from '@/lib/validateRequest';
import { handleApiError, handleUnauthorizedError } from '@/lib/errorHandler';
import { contactFormSchema } from '@/lib/validation';
import { auth } from '@clerk/nextjs/server';

async function handler(request: NextRequest) {
  try {
    const { userId } = await auth();
    if (!userId) return handleUnauthorizedError();

    const body = await request.json();
    const validation = validateRequest(contactFormSchema, body);

    if (!validation.success) {
      return validation.response;
    }

    const { name, email, subject, message } = validation.data;

    // Process form (send email, save to DB, etc.)

    return NextResponse.json({ success: true });
  } catch (error) {
    return handleApiError(error, 'contact-form');
  }
}

export const POST = withRateLimit(withCsrf(handler));
export const config = { runtime: 'nodejs' };

テンプレート 3：公開エンドポイント（認証なし、レート制限あり）

import { NextRequest, NextResponse } from 'next/server';
import { withRateLimit } from '@/lib/withRateLimit';
import { validateRequest } from '@/lib/validateRequest';
import { handleApiError } from '@/lib/errorHandler';
import { emailSchema } from '@/lib/validation';

async function handler(request: NextRequest) {
  try {
    const body = await request.json();
    const validation = validateRequest(emailSchema, body);

    if (!validation.success) {
      return validation.response;
    }

    const email = validation.data;

    // Process (e.g., newsletter signup)

    return NextResponse.json({ success: true });
  } catch (error) {
    return handleApiError(error, 'newsletter');
  }
}

export const POST = withRateLimit(handler);
export const config = { runtime: 'nodejs' };

やってはいけないこと - よくあるアンチパターン

❌ アンチパターン 1：セキュリティミドルウェアがない

// BAD - No protection
export async function POST(request: NextRequest) {
  const body = await request.json();
  // directly use body.field
  return NextResponse.json({ success: true });
}

問題点： レート制限も CSRF 対策も入力検証もありません。ブルートフォース攻撃、CSRF 攻撃、インジェクション攻撃に対して脆弱です。

❌ アンチパターン 2：入力検証を省略する

// BAD - No validation
async function handler(request: NextRequest) {
  const body = await request.json();
  const { title } = body; // Could contain <script> tags!
  await saveToDatabase(title);
}

問題点： XSS の脆弱性につながります。ユーザー入力がサニタイズされずに直接保存または表示されます。

❌ アンチパターン 3：本番環境でエラーの詳細を公開する

// BAD - Information leakage
catch (error) {
  return NextResponse.json({
    error: error.message,      // Could reveal internal paths
    stack: error.stack,        // Exposes code structure
    query: failedQuery         // Reveals database schema
  }, { status: 500 });
}

問題点： システム内部、データベース構造、ファイルパスを攻撃者に把握される手掛かりになります。

❌ アンチパターン 4：シークレットをハードコードする

// BAD - Hardcoded secret
const apiKey = 'sk_live_123456789';

// GOOD - Environment variable
const apiKey = process.env.API_KEY;

問題点： シークレットがバージョン管理に含まれ、リポジトリが侵害されると容易に漏えいします。

❌ アンチパターン 5：公開フォームにレート制限がない

// BAD - Can be spammed infinitely
export async function POST(request: NextRequest) {
  await sendEmail(data);
  return NextResponse.json({ success: true });
}

// GOOD - Rate limited
export const POST = withRateLimit(async (request: NextRequest) => {
  await sendEmail(data);
  return NextResponse.json({ success: true });
});

問題点： 攻撃者がエンドポイントにスパムを送信したり、コストを増大させたり、ブルートフォース攻撃を行ったりできます。

セキュリティ意識：AI コードの脆弱性を理解する

セキュリティ対策を実装する前に、AI がなぜ安全でないコードを生成するのか、またどのような脆弱性に注意すべきかを理解してください。

AI コードが安全でないことが多い理由

調査による統計：

• AI が生成したコードの 45% に安全でないパターンがあります（Veracode 2024）
• 36～72% に脆弱性が含まれています（言語によって異なります）（Georgetown CSET 2024）
• データベースクエリの 68% に SQL インジェクションの脆弱性があります（Aikido Security 2025）
• 81% がパスワードを安全でない方法で保存しています（Databricks 2025）

セキュリティ意識向上スキル

AI が生成したコードにおける特定の脆弱性カテゴリーについて学びます。

インジェクション攻撃を理解する： → security-awareness/injection-vulnerabilities - SQL インジェクション、コマンドインジェクション、XSS

• 実例：Equifax（1億4,700万件の記録）、British Airways（2,000万ポンドの罰金）
• AI がパラメーター化クエリではなく文字列連結を生成する理由
• 攻撃ベクトルと悪用のパターン

認証の欠陥を理解する： → security-awareness/auth-vulnerabilities - 安全でないパスワード、セッションの不備、アクセス制御

• 実例：Ashley Madison（3,200万アカウント）、Dropbox（6,800万アカウント）
• AI が MD5／平文のパスワードを提案する理由
• AI が認可チェックを忘れる理由

情報漏えいを理解する： → security-awareness/information-leakage - ハードコードされたシークレット、詳細すぎるログ

• 実例：AWS キーの露出（12時間で4万ドル）、ログに記録された決済データ
• AI が認証情報をハードコードする理由（学習データ）
• ログに記録してはいけない情報

サプライチェーンのリスクを理解する： → security-awareness/supply-chain-risks - 脆弱な依存関係、タイポスクワッティング

• 実例：event-stream の乗っ取り（週200万ダウンロード）、悪意あるパッケージ24万5,000件（2023年）
• AI が古いパッケージを提案する理由（67％に脆弱性あり）
• 依存関係の混乱攻撃

ビジネスロジックの欠陥を理解する： → security-awareness/business-logic-flaws - 競合状態、整数オーバーフロー

• 実例：フラッシュセールでの過剰販売、25万ドルの返金悪用
• ロジックの欠陥が機能テストを通過する理由
• 同時アクセスの脆弱性

リソース枯渇を理解する： → security-awareness/resource-exhaustion - 上限のない処理、コストの急増

• 実例：AI API の利用料が20万ドルに（4時間気付かれず）
• AI がリソース制限を追加しない理由
• DoS 攻撃のパターン

セキュリティ意識の全体像： → security-awareness/awareness-overview - AI セキュリティリスクの全体像

• 統計、調査、実際に発生した情報漏えい
• 安全なバイブコーディングへの道筋
• セキュリティを最優先するプロンプト作成のテクニック

次のステップ

タスクに応じて、適切なスキルを呼び出してください。

実装スキル（安全な構築方法）

• API ルートを保護する必要がありますか？ → csrf-protection スキル
• スパムや不正利用を防ぐ必要がありますか？ → rate-limiting スキル
• ユーザー入力を検証する必要がありますか？ → input-validation スキル
• ヘッダーを設定する必要がありますか？ → security-headers スキル
• エラー処理が必要ですか？ → error-handling スキル
• 認証が必要ですか？ → auth-security スキル
• 決済機能が必要ですか？ → payment-security スキル
• パッケージを更新する必要がありますか？ → dependency-security スキル
• セキュリティテストが必要ですか？ → security-testing スキル

運用スキル（デプロイと監視）

• どのミドルウェアを使えばよいですか？ → security-operations スキル
• 環境変数の設定が必要ですか？ → security-operations スキル
• デプロイ前のチェックリストが必要ですか？ → security-operations スキル
• セキュリティ監視の設定が必要ですか？ → security-operations スキル
• 保守スケジュールが必要ですか？ → security-operations スキル

意識向上スキル（リスクの理解）

• AI セキュリティリスクについて理解したいですか？ → security-awareness/awareness-overview スキル
• インジェクション攻撃について学びたいですか？ → security-awareness/injection-vulnerabilities スキル
• 認証の脆弱性について理解したいですか？ → security-awareness/auth-vulnerabilities スキル
• 露出したシークレットについて学びたいですか？ → security-awareness/information-leakage スキル
• サプライチェーンについて理解したいですか？ → security-awareness/supply-chain-risks スキル
• ロジックの欠陥について学びたいですか？ → security-awareness/business-logic-flaws スキル
• DoS のリスクについて理解したいですか？ → security-awareness/resource-exhaustion スキル

参考資料

• OWASP Top 10 2021: https://owasp.org/www-project-top-ten/
• OWASP Cheat Sheet Series: https://cheatsheetseries.owasp.org
• Next.js Security: https://nextjs.org/docs/app/guides/security
• Clerk Security: https://clerk.com/docs/security
• OWASP Defense in Depth: https://owasp.org/www-community/Defense_in_Depth