tanstack-start-security

@rules/auth-and-session.md @rules/server-boundaries.md @rules/http-and-headers.md @rules/validation.md @references/official-security-notes.md

TanStack Start のセキュリティ

<output_language>

この標準スキルファイルが英語で書かれていても、ユーザー向けの成果物、保存する成果物、レポート、計画、生成ドキュメント、要約、引き継ぎメモ、コミット／メッセージの草案、検証メモは、特に指定がない限り韓国語にしてください。

ソースコードの識別子、CLI コマンド、ファイルパス、スキーマキー、JSON/YAML のフィールド名、API 名、パッケージ名、固有名詞、引用されたソースの抜粋は、必要な言語または元の言語のままにしてください。

ユーザーが明示的に別の言語を指定した場合、既存の対象成果物との一貫性を保つために別の言語を維持する必要がある場合、または機械可読な仕様で正確な英語のトークンが必要な場合に限り、別の言語を使用してください。ローカライズされたテンプレートやリファレンス（例：*.ko.md や *.ko.json）がある場合は、ユーザー向けの成果物にはそちらを優先してください。

</output_language>

目的

すべての変更を全面的なセキュリティ再設計にすることなく、TanStack Start アプリケーションを強化します。

作業が TanStack Start アプリのセキュリティ態勢に特化している場合に、このスキルを使用してください。

• 認証とセッションの保護
• Cookie、CSRF、信頼済みオリジン、ブラウザーリクエストの安全性
• src/start.ts のリクエストミドルウェア
• サーバー関数とサーバールートの強化
• シークレットと環境変数の境界保護
• SSR、ハイドレーション、クライアント／サーバー実行時の情報漏えい
• セキュリティヘッダー、CSP、Webhook 検証、レート制限

一般的な React 作業や、セキュリティに関係しない文言修正には、このスキルを使用しないでください。

このスキルの出力形式はセキュリティ上の判断事項です。つまり、対象となるセキュリティ領域、その領域を規定するルールファイル、リスクを解消する最小限の変更、そしてリスクが解消されたことを示す検証結果です。成果物がリスク解消ではなくアーキテクチャ計画である作業（フォルダー構成、ルーティング規約、データ読み込みモデル、キャッシュの動作など）は、この形式に合いません。そのため、対象範囲を無理に広げず、実際に対象となるセキュリティ領域だけを強化して報告し、残りのアーキテクチャ項目はこのスキルの出力形式の対象外として明示してください。

依頼が TanStack Start に限定されない一般的なセキュリティレビューの場合は、TanStack Start のルールを無理に適用せず、通常のセキュリティレビューパスに振り分けてください。

<instruction_contract>

フィールド	契約
意図	すべての変更を全面的なセキュリティ再設計にすることなく、TanStack Start アプリの実際のセキュリティリスクを低減します。
範囲	TanStack Start プロジェクトにおける認証とセッション、Cookie／CSRF／信頼済みオリジン、シークレットと環境変数の公開、リクエストミドルウェア、サーバー関数、サーバールート、ヘッダー／CSP／CORS、Webhook、レート制限、SSR／ハイドレーション／インポート境界からの情報漏えいです。
権限	ユーザーおよびプロジェクトの指示は、このスキルより優先されます。TanStack Start および認証ライブラリの最新の公式ドキュメントは、内容が異なる場合、このスキルのメモより優先されます。中核となるセキュリティゲートは、ほかの希望にかかわらず変更をブロックします。
根拠	リポジトリの手がかり（app.config.ts、@tanstack/react-start、@tanstack/react-router、src/routes/__root.tsx）、変更対象のソースパス、それらを規定するルールファイル、プロジェクトのチェック結果です。
ツール	ローカルでの検索、読み取り、編集コマンドと、プロジェクト独自の lint、型チェック、テスト、ビルドコマンドです。ネットワークアクセス、認証情報の使用、破壊的なコマンドや本番環境に影響するコマンドには、ユーザーの明示的な承認が必要です。
ループ	ループはありません。対象となる領域のマッピングと修正を1回行い、続いてルールファイルのチェックリストを確認します。新しい領域に手を加えた場合、またはチェックに失敗した場合にのみ繰り返します。
出力	韓国語のセキュリティレポートまたは変更セットです。マッピングしたセキュリティ領域、各修正の根拠となるルールファイル、変更したファイル、検証コマンドとその結果、スタックに依存して残るリスクを含めます。
検証	変更したすべての領域について rules/validation.md のゲートとプロジェクト独自のチェックを実行し、正確なコマンドと結果を記録します。
停止条件	マッピングした各領域が強化済み、または明示的に保留され、関連するルールファイルのゲートに合格し、検証結果が記録され、スタックに依存して残るリスクが明示されたら停止します。

</instruction_contract>

トリガーの例

肯定的な例：

• TanStack Start のログインとセッション処理のセキュリティをレビューする。
• TanStack Start のサーバー関数からシークレットが漏えいしないようにする。
• この TanStack Start アプリの認証、Cookie、CSRF、Webhook のセキュリティをレビューする。

否定的な例：

• 通常の React ページに、スタイルのみの小さな変更を加える。
• TanStack Start アプリではない Express API サーバーのセキュリティをレビューする。

境界の例：

• TanStack Start ページの文言だけを変更する。 セキュリティ境界、認証、環境変数の処理、サーバールート、ヘッダーに変更がない場合、このスキルは適用範囲が広すぎる可能性があります。

ステップ 1：プロジェクトの検証

リポジトリが次のような TanStack Start のシグナルを実際に使用している場合に限り、このスキルを適用してください。

• app.config.ts
• package.json 内の @tanstack/react-start
• package.json 内の @tanstack/react-router
• src/routes/__root.tsx

これらのシグナルが見つからない場合は、作業を中止し、通常の実装またはセキュリティレビューの手順に切り替えてください。

ステップ 2：適切なルールを読む

セキュリティに関わるコードを編集する前に、次のファイルを読んでください。

• rules/auth-and-session.md：認証、認可、Cookie、リクエストのオリジンに関するルール
• rules/server-boundaries.md：createServerFn、createServerOnlyFn、環境変数／シークレット、インポート境界に関するルール
• rules/http-and-headers.md：サーバールート、CSP、ヘッダー、CORS、レート制限、Webhook の処理に関するルール
• rules/validation.md：レビューのゲートと検証手順

認証スタックの詳細、TanStack の実行ルール、または Better Auth 固有の情報が関係する場合は、references/official-security-notes.md を読んでください。

プロンプトの種類に応じた開始箇所

• 認証、セッション、Cookie、CSRF、beforeLoad、認可に関する問題：rules/auth-and-session.md から開始します
• シークレットの漏えい、環境変数の露出、loader、SSR コンテキスト、ハイドレーション時の漏えい、インポート境界に関する問題：rules/server-boundaries.md から開始します
• src/start.ts のミドルウェア、CSP、CORS、ヘッダー、Webhook、レート制限、サーバールートに関する問題：rules/http-and-headers.md から開始します
• プロンプトがコピーのみの編集、または TanStack に関係しないセキュリティ依頼の場合は、コア境界の判断までで中止し、詳細なファイルを読むのではなく、適切な手順に切り替えます

ステップ 3：セキュリティ対象のマッピング

コードを変更する前に、どのセキュリティ領域に触れるかをマッピングしてください。

1. 認証／セッション
2. シークレット／環境変数
3. src/start.ts のリクエストミドルウェア
4. サーバー関数
5. サーバールート／HTTP エンドポイント
6. ブラウザーに配信されるヘッダーと CSP
7. SSR／ハイドレーション／インポート境界の漏えい

複数の領域に影響する場合は、編集前に関連するすべてのルールファイルを確認してください。

ステップ 4：推奨する修正の順序

実際のリスクを解消する、最小限の修正を行ってください。

1. まずシークレットまたは境界の漏えいを止めます
2. 次にセッション／認可の適用を追加します
3. Cookie、オリジン、変更処理の安全性を強化します
4. 明示的なヘッダー、CSP、Webhook チェック、レート制限を追加します
5. その後で初めて、大規模な認証スタックやルート構造の移行を検討します

ステップ 5：自動修正の方針

変更が局所的で、元に戻せて、明らかに安全性を高める場合は、直接自動修正してください。

• 特権ロジックを createServerFn または createServerOnlyFn の内側に移動する
• ルート／セッションのガードチェックを追加する
• クライアントに公開されるシークレットへのアクセスを、サーバー専用のアクセスに置き換える
• 不足している入力検証またはオリジン／署名チェックを追加する
• 現在のスタックが明確な場合は、Cookie またはヘッダーのデフォルト設定を強化する

明示的な根拠なしに、広範囲でリスクの高い移行を自動適用しないでください。

• 認証ライブラリの置き換え
• セッションモデルの大規模な変更
• アセット／スクリプト要件を確認せずに行う、サイト全体の CSP の書き換え
• 環境をまたぐ広範な CORS または Cookie ドメインの変更

コアセキュリティゲート

次のいずれかに該当する場合、修正されるまで変更をブロックしてください。

• クライアントから到達可能なコードが、シークレットをインポートまたは導出できる
• 保護対象データの変更処理が、クライアントから提供された ID またはロールの情報を信頼している
• TanStack Start の loader または共有ユーティリティが、明示的なサーバー境界なしで特権処理を実行している
• 保護対象のアクションに対する同等のサーバー側保護がないまま、ルートが beforeLoad のみに依存している
• loader の出力、SSR コンテキスト、またはハイドレーションされた状態に、シークレットや内部専用の認証データがシリアライズされている
• サーバールートが、認証／オリジン／CSRF 戦略なしで、ブラウザーからの状態変更入力を受け付けている
• Webhook ハンドラーが、署名を検証する前にペイロードを信頼している
• 認証／セッション Cookie が、意図した環境ごとのルールなしに緩く設定されている

<validation_checklist>

検証

完了を報告する前に、次の項目を確認してください。

• 該当するルールファイルのチェックリストを確認します
• 変更によってアプリが壊れていないことを証明するプロジェクトのチェックを実行します
• 強化した内容と、スタックに依存する事項を要約します

詳しいレビューとコマンドのガイダンスについては、rules/validation.mdを参照してください。

</validation_checklist>