FixVibe

// docs / security guides / lovable checklist

Lovable security checklist: 25 items before launch

Lovable is a fast path from idea to a published full-stack app on Supabase and Vite. This checklist targets the risks that come with that stack: RLS that must be enabled and tightened on every table Lovable creates, test keys from integrations, import.meta.env leaking env vars into the Vite bundle, GitHub sync exposing secrets, and missing security headers. 25 items across secrets, database, auth, headers, deployment, and Lovable-specific gotchas.

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

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

Lovable のマーケットプレイス統合と Vite ビルドは、注意しないと環境変数がクライアント バンドルに漏洩する可能性があります。

  1. PRE — Audit import.meta.env references. Vite は、すべての VITE_ 接頭辞が付いた変数をクライアントで import.meta.env.VITE_* として公開します。 VITE_SUPABASE_SERVICE_KEY や VITE_STRIPE_SECRET は決して使用しないでください。代わりに、サーバーのみのエンドポイントを介してルーティングします。
  2. PRE — Replace Lovable marketplace test keys with live restricted keys. Lovable の Stripe / 再送信 / などの統合には、sk_test_* または pk_test_* キーが付属している場合があります。公開する前に、侵害された場合の被害を制限する公開制限付きキーと交換してください。
  3. PRE — Check the .env file is not committed. Lovable は、統合キーを使用して .env ファイルをスキャフォールディングします。 git ls-files .env を実行します。追跡されている場合は、すぐに削除してください: git rm --cached .env を .gitignore に追加します。
  4. PRE — Verify GitHub sync doesn't expose service keys. Lovable が GitHub に同期する場合は、GitHub アクション ワークフローまたは Vercel 設定がビルド ログにシークレットをエコーしないことを確認してください。アクションを確認し、ワークフローを実行し、実行をクリックし、シークレットが出力されるかどうかを確認します。
  5. POST — Run Secrets in JavaScript Bundles on the deployed app. Lovable の Vite ビルドではキーが import.meta.env に漏洩する可能性があります。パッシブスキャンでそれらが見つかります。

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

Every table Lovable creates needs RLS enabled and tightened before production.

  1. PRE — Enable RLS on every public table. In Supabase Studio, Tables → for each public.* table → the RLS toggle must be ON, with policies for each command.
  2. PRE — Write explicit policies per table and role. 最小値: SELECT では、ユーザーは user_id = auth.uid() の行のみを読み取ることができます。 Lovable はポリシーのないテーブルを生成することがあります。それらを追加する必要があります。
  3. PRE — Check Lovable's generated policies, not just the toggle. A policy such as USING (true) keeps RLS "on" while letting every caller through. Scope each policy to auth.uid(). (FORCE ROW LEVEL SECURITY only affects the table owner; it does not fix an open policy.)
  4. DEPLOY — Re-verify RLS is enforced after deploy. デプロイ後に Supabase Studio を開きます。各テーブルの RLS 切り替えは ON である必要があります。そうでない場合は、移行は適用されませんでした。
  5. 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 項目)

Lovable の認証は Supabase 認証です。リスクは、Lovable がそれをどのように接続するかにあります。

  1. PRE — Ensure all API routes use getUser(), not getSession(). getSession() は未検証の Cookie を読み取ります。 getUser() は Supabase で検証されます。 API ハンドラーで getSession() を検索し、置き換えます。
  2. PRE — Check Lovable's generated auth handlers for token expiry. マジックリンク トークンにはサーバーによる有効期限が必要です。デフォルトは 1 時間です。必須でない限り、上書きしないでください。
  3. PRE — Audit the sign-in redirect guard. next クエリ パラメータは / で始める必要があり、// は使用できません。不足している場合は、ガードを手動で追加します。
  4. POST — Test logout destroys the session. サインイン、サインアウトし、Cookie を検査します (DevTools → Application → Cookie)。セッション Cookie をクリアする必要があります。

HTTP ヘッダーと CSP (3 項目)

Lovable の Vite scaffold は、デフォルトでは CSP を追加しません。静的ホストには明示的なヘッダー構成が必要です。

  1. PRE — Add security headers via your host's config. Vercel: vercel.json headers 配列。 Netlify: _headers ファイル。 CSP、HSTS、X-Frame-Options、X-Content-Type-Options を含めます。
  2. PRE — CSP must not have 'unsafe-inline' in script-src. nonce またはハッシュを使用します。 Lovable の Vite ビルドは厳密な CSP で動作します。
  3. POST — Run HTTP Security Headers on the deployed URL. このチェックでは、欠落しているヘッダーが報告され、プラットフォーム固有の修正ガイダンスが提供されます。

展開時の衛生管理 (5 項目)

Lovable hosts published apps itself (Lovable docs). If you export the code and deploy it to Vercel, Netlify or Cloudflare Pages instead, each host handles headers and env vars differently.

  1. DEPLOY — Scope env vars to Production only. Vercel: 設定 → 環境変数 → それぞれのスコープを Production に設定します。テスト用の Stripe キーをプレビューと共有しないでください。
  2. DEPLOY — Verify build logs don't echo secrets. デプロイメントプロバイダーのビルドログを確認してください。秘密が印刷されると、それは危険にさらされます。
  3. DEPLOY — Add security headers to vercel.json or _headers. Vercel には、headers 設定を使用します。 Netlify / Cloudflare の場合は、パブリック ディレクトリの _headers ファイルを使用します。
  4. POST — Test a Vercel Preview link in a private browser window. CSP ノンスが各リクエストで最新であり、ヘッダーが存在することを確認してください。
  5. POST — Rotate any test key that ever shipped to production. たとえ sk_test_* キーであっても、運用環境で確認した後でローテーションしてください。

Lovable 特有の注意点 (3 項目)

Lovable のスキャフォールドと展開フローに特有のパターン:

  1. import.meta.env is Vite-specific and all-or-nothing. Vite は設計上、クライアント バンドルで VITE_* 変数を公開します。 Vite には、個別の API 境界のないサーバー専用環境の概念はありません。 Lovable のデフォルトはクライアントヘビーです。機密性の高い操作には API ルートを追加する必要があります。
  2. GitHub sync can auto-commit without review. Lovable の同期が GitHub に戻った場合は、ワークフローが承認なしに自動プッシュされていないことを確認してください。そうしないと、悪意のあるアップデートがメインに侵入する可能性があります。
  3. Static-host headers are a different beast than middleware. Vercel、Netlify、および Cloudflare ページはすべて、ヘッダーの処理方法が異なります。ホストを切り替える場合は、ヘッダー構成が適用されていることを再確認してください。ヘッダーがサポートされていない場合でも、プラットフォームはエラーを返さない可能性があります。

次のステップ

51 個のクロスツール項目については general vibe coding security checklist を確認してください。 CSP、RLS、および認証に関するより詳細なパターンについては、step-by-step hardening を参照してください。

// scan your app

読むのは終わりにして、自分のアプリの穴を見つけよう。

Drop in a URL — FixVibe runs every passive check from this guide plus the rest of its 230+ passive checks, usually in under a minute. Free, no install, no card.

  • Free 層 — 月あたり 3 回のスキャン、カードなし。
  • あらゆる URL に対するパッシブ スキャン - ドメイン検証は必要ありません。
  • Cursor、Claude Code、Lovable、Bolt、v0、Replit 用に調整されています。
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
無料スキャンを実行 →

サインアップ不要

Lovable security checklist: 25 items before launch · FixVibe