AIで作ったアプリを公開する前に確認すべき Supabase Auth の設定

Lovable や Bolt などのAIツールにログイン機能を追加してもらうと、画面とコードはツールが書いてくれます。しかし、そのログインがどれだけ安全かを決める設定は別の場所にあります。Supabase プロジェクトの Authentication の中で、その多くはプロジェクトを作成したときの値のままです。

初期値は、使い始めるためのものであり、実際のユーザーを迎えるためのものではありません。この記事では、公開前に変えておきたい設定を、私たちが確認する順に説明します。どれもコードは不要で、ほとんどは1分で終わります。

1. Site URL と Redirect URLs #

登録の確認、マジックリンク、パスワードの再設定のあと、Supabase はユーザーをアプリに戻します。Site URL はその既定の戻り先で、Redirect URLs はそれ以外に許可するアドレスの一覧です。

• Site URL には http://localhost:3000 ではなく、本番のアドレス https://yourapp.com を設定します。確認メールや再設定メールはこのアドレスを使います。
• Redirect URLs には、本番のアドレスを正確に書きます。ローカル開発やプレビュー用にワイルドカードを使うのは構いませんが、範囲はできるだけ狭くします。

2. メールアドレスの確認 #

Confirm email がオフになっていると、誰でも他人のメールアドレスで登録し、そのアカウントをすぐに使えてしまいます。特別な理由がない限り、メールプロバイダーの設定でオンにし、アプリが「受信トレイを確認してください」という手順を正しく扱えるようにしておきましょう。

3. 独自のメール送信（SMTP） #

Supabase に組み込まれているメール送信はテスト用です。送信先は組織のメンバーに限られ、認証メールの上限は初期設定で1時間に2通です。つまり公開当日、2人目の新規ユーザーには確認メールが届きません。

メール配信サービス（Resend、Postmark、Amazon SES、Brevo など）を使い、自社ドメインで Custom SMTP を設定します。そうすれば確認メールは no-reply@yourapp.com から届き、メールの送信上限も引き上げられます。これらのメールを迷惑メールではなく受信トレイに届けるには、ドメインに SPF、DKIM、DMARC が必要です。お問い合わせフォームのメールで説明したのと同じレコードです。

4. パスワードのルール #

パスワードの設定では、次の点を確認します。

• 最小文字数： Supabase は8文字未満を推奨していません。私たちは10文字以上にしています。
• 必須の文字種： 英字と数字を必須にすると、利用者の手間をあまり増やさずに、最も弱いパスワードを防げます。
• 漏洩したパスワードからの保護（Leaked password protection）： 既知のデータ漏洩に含まれるパスワードを拒否します（HaveIBeenPwned で照合）。Pro プラン以上で利用できるので、Pro プランならオンにしてください。

5. リンクとコードの有効期限 #

マジックリンクやワンタイムコードは、有効な間はパスワードと同じ力を持ちます。Supabase は有効期限を1時間（3600秒）以下にするよう推奨しています。ユーザーがコードでログインするなら、短いほど安全です。

6. 登録、ログイン、パスワード再設定の CAPTCHA #

登録フォームを見つけたボットは、偽のアカウントを作り、メールの送信枠を使い果たし、ログインフォームで漏洩したパスワードを試します。Supabase Auth は、登録、ログイン、パスワード再設定で Cloudflare Turnstile または hCaptcha による CAPTCHA に対応しています。ダッシュボード（ボットと不正利用の対策の項目）でオンにし、フォームにウィジェットを追加して、呼び出しの際にトークンを渡します。

await supabase.auth.signUp({
  email,
  password,
  options: { captchaToken } // from the Turnstile or hCaptcha widget
});

Turnstile は通常、実際の訪問者には見えません。CAPTCHA をオンにすると、登録、ログイン、再設定のすべての呼び出しにトークンが必要になるため、有効にする前にすべてのフォームを更新しておいてください。

7. 新規登録と、使っていないプロバイダー #

• チームや招待した顧客など、限られた人向けのアプリなら、Allow new users to sign up をオフにし、招待で利用者を追加します。
• 使っていないプロバイダーはオフにします。有効なプロバイダーは、それだけ入口が増えることを意味します。
• Anonymous sign-ins（匿名ログイン）は個別に確認が必要です。匿名ユーザーにも authenticated ロールが付くため、「ログインしているユーザーなら誰でも読める」というポリシーは、「ゲストとして続ける」を押しただけの人にも読ませてしまいます。匿名ログインを使うなら、重要なポリシーで is_anonymous クレームを確認してください。使わないなら、オフのままにしておきます。

8. メールアドレスとパスワードの変更 #

盗まれたセッションがアカウントの乗っ取りにつながるのは、メールアドレスやパスワードの変更を通じてです。Secure email change（変更を新旧両方のアドレスで確認する機能）はオンのままにし、プランと設定で可能なら、パスワード変更の前に直近のログインを求めるようにします。

9. レート制限 #

Supabase は、登録、ログイン、コードの要求、トークンの更新にレート制限をかけています。Auth の設定で Rate Limits を開き、一度目を通しておきましょう。Custom SMTP を設定したら、メールの上限を公開当日に必要な数まで引き上げます。それ以外は、理由がなければそのままで構いません。

10. 多要素認証（少なくとも管理者には） #

管理画面がある、あるいはお金や健康に関するデータを扱うアプリなら、多要素認証を用意し、管理者には必須にしましょう。そうすれば、重要なテーブルのポリシーで多要素認証を条件にできます。ユーザーのトークンには、2つ目の要素でログインしたかどうか（aal2）が含まれています。

これらの設定で防げないこと #

Auth の設定が決めるのは、誰がログインできるかです。ログインしたユーザーが何を読み、何を変更できるかは決めません。それはデータベースの Row Level Security の役割です。まだ確認していなければ、10分でできる RLS チェックから始め、アプリのそのほかの部分は公開前のセキュリティチェックリストで確認してください。

無料の Security Check では、公開中のアプリを外部から読み取り専用で確認します。認証の設定やデータベースのルールも含めて調べ、深刻な問題を書面でお伝えします。