Lovableで作ったアプリを、動く状態から本番で運用できる状態へ

よくある問題

何で作ったかにかかわらず、レビューが追いつかない速さで育ったアプリによく見られる問題です。ほとんどは、今の環境のまま直せます。

1. 誰でも読めるテーブル

   Supabaseを使うLovableアプリは、すべてのブラウザに公開用のキーを送ります。これは設計どおりの動きで、利用者ごとにどの行を読み書きできるかを決めるのは行レベルセキュリティ（RLS）です。RLSがなければ、公開用のキーだけでテーブルが開いてしまいます。

   Supabaseを使うLovable製のアプリが、行レベルセキュリティ（RLS）のないまま公開された事例があり、CVE-2025-48757として登録されています。 Wikipedia（英語）：Lovable

2. 設定はあっても、正しくないアクセスルール

   RLSが有効になっていることと、RLSが正しいことは別の話です。サインインした利用者なら誰でも全行を読めるポリシーや、ブラウザが送ってくるユーザーIDをそのまま信用するポリシーもありえます。それを確かめるには、誰が何を見るべきかを理解している人の目が必要です。

3. ブラウザに置かれたシークレット

   有料APIや決済、メール配信サービスのキーは、サーバーかEdge Functionに置くもので、ブラウザがダウンロードするコードに含めてはいけません。ブラウザに配信したものは、ページを開いた誰にでも読めます。

   Escape.techが、バイブコーディングで作られ公開されているアプリ5,600件を調べたところ、影響の大きい脆弱性が2,000件以上、露出したシークレットが400件以上、個人情報の露出が175件見つかりました。 Escape.tech（英語）

4. 画面の上にしかないルール

   ボタンを隠すことで実現しているペイウォールや管理画面、利用上限は、実際には守られていません。同じルールを、データのある場所でも守らせる必要があります。

5. 安全網のない変更

   プロンプトによる変更は、ある機能を直す一方で、別の機能を気づかないうちに壊すことがあります。売上に関わる流れにテストがなく、変更を試せるステージング環境もなければ、問題が見つかるのは本番です。

   Veracodeの調査では、AIによるコード生成タスクの45%で脆弱性が入り込み、モデルが進歩してもセキュリティ面の成績は「時間がたっても変わっていない」とされています。 Veracode、BusinessWire経由（英語）

Lovableアプリで監査が確認すること

コード・プロダクト監査では、外から見える部分だけでなくコードそのものを読み、すべての指摘を事業への影響で順位づけします。Lovableアプリの場合は、次の点を確認します。

• Supabaseのすべてのテーブルとストレージのバケット。RLSが有効か、各ポリシーが「誰が何を見るべきか」と合っているか。
• 認証。サインアップ、メールアドレスの確認、パスワードの再設定、セッション、ロール。
• 配信されるJavaScriptとEdge Functionに含まれる、キーとシークレット。
• 決済の流れ。チェックアウトから、利用権限を付与するWebhookまで。
• 変更が本番に届くまでの流れ。GitHub連携、環境、変更がうまくいかなかったときの対応。
• 利用者が待たされるページのパフォーマンス。
• プロダクトと事業の目標。お話をうかがい、すべての指摘を事業にとっての意味で順位づけします。

公開中のアプリを1日で確認する、固定価格のローンチチェックもご用意しています。認証、RLS（行レベルセキュリティ）とデータアクセス、シークレットを確認し、リスクの大きいものから5件を30分のお打ち合わせでご説明します。 ローンチチェックについて

今の環境のまま、本番で通用する状態へ

基本のご提案は、Lovableのまま、今のアプリを本番の運用に耐えられるようにすることです。Lovableからの移行は、監査でその費用に見合うとわかった場合にだけご提案します。

Lovableアプリを、まず無料チェックで

無料チェックは、配信されているJavaScriptに含まれるキー、ヘッダー、HTTPS、バージョンなど、アプリがすでに外に見せているものをスキャンし、2営業日以内にAaronが結果を確認します。メールでのご確認と、アプリの所有者であることの確認が済んでから実行します。