// docs / security guides / cursor checklist
Cursor セキュリティチェックリスト: リリース前の 28 項目
Cursor で構築しますか? Cursor のオートコンプリート、コンポーザー モード、およびエージェント機能は非常に強力であり、予測可能なセキュリティの盲点を生み出します。このチェックリストは、Cursor 固有のパターン (サービスロール キーのインライン化、レビューなしで Composer によって生成されたファイル全体、エージェント モードのターミナル コマンド、最初のセキュリティ ガードレールとしての <code>.cursorrules</code> ファイル) を対象としています。シークレット、データベース、認証、ヘッダー、デプロイメント、および Cursor 固有の注意事項にわたる 28 の項目。
PRE = 事前デプロイ (ソースを監査)。 DEPLOY = デプロイ時。 POST = デプロイ後の検証。項目は FixVibe を参照し、該当する場合は category.check-id フォームの ID を確認します。
シークレットと API キー (5 項目)
Cursor のオートコンプリートは、シークレットが一般的なオープンソース コードでトレーニングされています。モデルは、特に認証試行が失敗した後、それらを自由に提案します。
- PRE — Write security rules into
.cursorrules. 行を追加します。「SUPABASE_SERVICE_ROLE_KEY、sk_live_*、またはプロバイダーの頭字語で始まる環境変数をクライアント側のコードにインライン化しないでください。常にサーバーのみのインポートを使用してください。」 Cursor は.cursorrulesを読み取り、それをすべての提案に組み込みます。 - PRE — Audit Composer-generated files. Cursor の Composer がファイル全体 (特に認証ハンドラー) を作成するときは、それを 1 行ずつ確認してください。 Composer は、サーバー専用である必要がある環境変数をインライン化することがあります。コンポーネントのインポートで
NEXT_PUBLIC_またはサービス キーへの直接参照を探します。 - PRE — Reject auto-imports of service clients into client components. Composer が
import { supabase } from '@/lib/supabase/service'を React ファイルにインポートする場合は、そのファイルをすぐに削除し、代わりに API エンドポイント経由でルーティングします。サーバーのみのインポートは明示的にマークされています。スキップしないでください。 - PRE — Scan Agent-mode commits. エージェント モードではターミナル コマンドが実行され、直接コミットできます。
git log --oneline -20とgit diff HEAD~5を監査して、エージェントの実行中に秘密に見える文字列がコミットされていないことを確認します。 - POST — Run secrets.browser-storage. デプロイされた URL でのパッシブ スキャン。サービス キーが JS バンドルに含まれている場合は、すぐにローテーションしてください。おそらく Cursor のオートコンプリートによってインライン化されています。
データベースアクセス制御（4項目）
Composer は、機能する認証コードを生成することがよくありますが、RLS をスキップします。「機能した」瞬間は、ポリシーの適用が欠落していることに人々を盲目にします。
- PRE — Force Cursor to generate migrations with RLS.
.cursorrules: 「CREATE TABLE public.*の移行にはALTER TABLE ... ENABLE ROW LEVEL SECURITYとFORCE ROW LEVEL SECURITYを含める必要があります。」次に、Composer に移行を生成するように依頼します。 - PRE — Review Composer-generated policies. Composer は
auth.uid()をチェックせずにポリシーを作成することがあります。using句のないallow select on public.itemsのようなポリシーは危険なほど範囲が広いです。 user_id の一致が必要です。 - DEPLOY — Confirm
FORCE ROW LEVEL SECURITYis live. Supabase Studio を開き、各テーブルの RLS の切り替えを確認します。 Composer の移行にENABLEがあり、FORCEが忘れられた場合、テーブル所有者 (移行) は RLS をバイパスします。これは本当のギャップです。 - POST — Run the baas.supabase-rls active check. anon キーを使用して書き込みを試みます。成功した場合、RLS は実際には強制されていません。おそらく
FORCEキーワードが欠落している可能性があります。
認証とセッション (4 項目)
Cursor は認証フローを迅速に生成しますが、トークンを安全に保つサーバー側の微妙な検証を見逃すことがよくあります。
- PRE — Ensure all auth routes use
getUser(). API ルートでgetSession()を検索し、await supabase.auth.getUser()に置き換えます。getSession()は未検証の Cookie を読み取ります。getUser()は Supabase バックエンドで検証します。 - PRE — Check Composer auth handlers for token expiry. マジックリンク トークンにはサーバーによる
expires_atが必要です。デフォルトの Supabase は 1 時間です。本当の理由がない限り、Cursor にオーバーライドを依頼しないでください。 - PRE — Audit the sign-in redirect guard. サインイン後の
nextクエリ パラメータ リダイレクトを検証する必要があります。/で始める必要があり、//は使用できません。 Composer はこれをスキップすることがあります。不足している場合は手動で追加します。 - POST — Test logout server-side state destruction. サインイン、サインアウトし、Cookie を検査します (DevTools → Application → Cookie)。セッション Cookie は直ちにクリアする必要があります。継続する場合、ログアウト ハンドラーは状態を破壊していません。
HTTP セキュリティヘッダーと CSP (3 項目)
Cursor がデフォルトでミドルウェアを生成することはほとんどありません。明示的に要求しない限り、CSP と HSTS は通常存在しません。
- PRE — Demand CSP in
.cursorrules. 追加: 「Content-Security-Policy を使用してsrc/middleware.tsを生成します。script-src には nonce を使用し、unsafe-inline は使用しません。」次に、Cursor に生成するよう依頼します。このヒントがないと、ミドルウェアはスキップされます。 - PRE — Verify
src/middleware.tsexists.src/ディレクトリ レイアウトでは、Next.js はsrc/middleware.tsのみを選択します。ルートレベルのmiddleware.tsは黙って無視されます。 CSP が起動しない場合は、ファイルが正しい場所にあることを確認してください。 - POST — Run headers.security-headers. パッシブ スキャンでは、CSP、HSTS、X-Frame-Options、X-Content-Type-Options が欠落していると報告されます。レポートを開いて、展開プラットフォームの修正ガイダンスに従ってください。
展開時の衛生管理 (5 項目)
Cursor アプリは Vercel に配置されることが多く、デフォルトは良好ですが、build/deploy 境界を明示的に強化する必要があります。
- DEPLOY — Check Vercel env-var scoping. [設定] → [環境変数] → 各シークレットのスコープは Production のみに設定する必要があります。
sk_live_*をプレビューまたは開発と共有しないでください。 - DEPLOY — Disable build-log secret echo.
vercel.jsonまたは GitHub アクション ワークフローにecho $SECRETがある場合は、それを削除します。ビルド ログはパブリックにアーカイブされます。ログ内の秘密が侵害されます。 - DEPLOY — Use Vercel's managed secrets, not inline workflow vars. Vercel の設定→環境変数は保存時に暗号化されます。 GitHub アクションのシークレットは何もしないよりは優れていますが、デプロイメント プラットフォームの統合ではなく、CI 向けに設計されています。
- POST — Verify CSP nonce on the deployed preview. ブラウザで Vercel プレビュー リンクを開き、DevTools → ネットワーク → ルート HTML 応答を開きます。 CSP ヘッダーが存在し、リクエストごとに一意のノンスを含む
'strict-dynamic'が含まれている必要があります。 - POST — Rotate any key that ever shipped, even to Preview. キーが本番バンドルに 10 分間でも到達すると、そのキーは侵害されます。すぐに回転させます。
Cursor 特有の注意点 (4 項目)
セキュリティ リスクを生み出す Cursor のワークフローに特有のパターン:
- Agent mode auto-fixes propagate old patterns. エージェントに「認証エラーの修正」を依頼すると、同じ認証ファイルが複数回再生成され、コードベース コンテキスト内にある場合はそのたびに同じサービス キーがインライン化されることがあります。まずオリジナルをクリーニングしてから、エージェントに修正を依頼してください。
- Cursor Index leaks intent. Cursor の
@codebaseインデックス作成は強力ですが、.cursorディレクトリが公開された場合 (S3 の設定ミス、git 履歴)、インデックスによってアーキテクチャと秘密のパターンが明らかになります。.cursorをローカルに保ちます。 - Composer mode loses context between files. Composer が生成する各ファイルは新鮮です。クライアント ファイルを生成してから API ルートを生成するように依頼すると、異なる Supabase クライアント構成が使用される可能性があります。両方を確認して、アーキテクチャに一致していることを確認してください。
- Autocomplete bias toward "working" over "secure". Cursor は、現在のコンテキストを渡す最速のコードを提案します。テストに
NEXT_PUBLIC_SERVICE_KEYが含まれている場合、オートコンプリートはそれを記憶し、再提案します。コードをモデルと共有する前に、テスト フィクスチャをクリーンアップします。
次のステップ
Cursor 固有のパターンを特定したら、general vibe coding security checklist (44 項目)、次に step-by-step hardening と照合してください。ツールを混合する場合は、Claude Code checklist も参照してください。