// docs / security guides / cursor checklist

Cursor security checklist: 25 items before ship

Building with Cursor? Cursor's autocomplete and Agent features are exceptionally powerful — and create predictable security blind spots. This checklist targets Cursor-specific patterns: service-role key inlining, generated multi-file edits merged without review, Agent-mode terminal commands, and project rules (.cursor/rules) as your first security guardrail. 25 items across secrets, database, auth, headers, deployment, and Cursor-specific gotchas.

PRE = pre-deploy (audit your source). DEPLOY = at deploy time. POST = post-deploy verification.

シークレットと API キー (5 項目)

Cursor のオートコンプリートは、シークレットが一般的なオープンソースコードでトレーニングされています。モデルは、特に認証試行が失敗した後、それらを自由に提案します。

PRE — Write security rules into your project rules. Add a rule in .cursor/rules (Cursor docs): "Never inline SUPABASE_SERVICE_ROLE_KEY, sk_live_*, or any server secret into client-side code. Always use server-only imports." Cursor applies project rules as context for Agent and chat.
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 in JavaScript Bundles. デプロイされた URL でのパッシブスキャン。サービスキーが JS バンドルに含まれている場合は、すぐにローテーションしてください。おそらく Cursor のオートコンプリートによってインライン化されています。

データベースアクセス制御（4項目）

Composer は、機能する認証コードを生成することがよくありますが、RLS をスキップします。「機能した」瞬間は、ポリシーの適用が欠落していることに人々を盲目にします。

PRE — Make Cursor generate migrations with RLS. In your project rules: "Every CREATE TABLE public.* migration must include ALTER TABLE ... ENABLE ROW LEVEL SECURITY and a policy per command scoped to auth.uid()." Then ask Cursor to generate the migration.
PRE — Review Composer-generated policies. Composer は auth.uid() をチェックせずにポリシーを作成することがあります。 using 句のない allow select on public.items のようなポリシーは危険なほど範囲が広いです。 user_id の一致が必要です。
DEPLOY — Confirm RLS and policies are live. Open Supabase Studio and check that every table's RLS toggle is on and that each table has policies. A table with RLS on and no policies denies everything; one with USING (true) allows everyone.
POST — Run a FixVibe scan on the deployed app. Check the Supabase Row-Level Security result: it shows any table an anonymous visitor can read with your public key.

認証とセッション (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 your project rules. Add: "Generate a src/middleware.ts with Content-Security-Policy. Use nonce for script-src, no unsafe-inline." Then ask Cursor to generate it. Without this hint, middleware is skipped.
PRE — Verify src/middleware.ts exists. src/ ディレクトリレイアウトでは、Next.js は src/middleware.ts のみを選択します。ルートレベルの middleware.ts は黙って無視されます。 CSP が起動しない場合は、ファイルが正しい場所にあることを確認してください。
POST — Run HTTP 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 (51 項目)、次に step-by-step hardening と照合してください。ツールを混合する場合は、Claude Code checklist も参照してください。