AI 开发的应用上线前，要检查的 Supabase Auth 设置

当 Lovable、Bolt 或其他 AI 工具为你的应用加上登录功能时，它会写好界面和代码。但决定登录有多安全的设置在别处：在你的 Supabase 项目的 Authentication 下面，而且其中大部分仍是项目创建时的默认值。

这些默认值是为了方便起步，而不是为真实用户准备的。本文按我们检查的顺序，逐一介绍上线前值得修改的设置。它们都不需要写代码，大多数一分钟就能完成。

1. Site URL 和重定向网址 #

用户完成注册确认、点击魔法链接或重置密码后，Supabase 会把用户送回你的应用。Site URL 是默认的目的地；Redirect URLs 是允许使用的其他地址列表。

• 把 Site URL 设为你的生产环境地址 https://yourapp.com，而不是 http://localhost:3000。确认邮件和重置邮件都会使用它。
• 在 Redirect URLs 中列出准确的生产环境地址。本地开发和预览可以使用通配符，但范围要尽量窄。

2. 邮箱确认 #

关闭 Confirm email 后，任何人都可以用别人的邮箱地址注册，并立即使用这个账户。除非有特别的理由，否则请在邮箱登录方式的设置中开启它，并确保应用能处理"请查收邮件"这一步。

3. 使用自己的邮件发送服务（SMTP） #

Supabase 内置的邮件发送服务只用于测试。它只会向你组织中的成员发信，而且认证邮件的默认上限是每小时 2 封，所以在上线当天，你的第二位新用户就收不到确认邮件了。

请通过邮件发送服务（Resend、Postmark、Amazon SES、Brevo 等）在你自己的域名上配置自定义 SMTP。这样确认邮件会来自 no-reply@yourapp.com，你也可以提高邮件发送上限。要让这些邮件进入收件箱而不是垃圾箱，域名需要配置 SPF、DKIM 和 DMARC，和我们在联系表单邮件一文中介绍的记录相同。

4. 密码规则 #

在密码设置中：

• 最短长度： Supabase 建议不要低于 8 个字符。我们使用 10 个或更多。
• 必需字符： 要求同时包含字母和数字，可以挡住最弱的密码，又不会给用户带来太多麻烦。
• 泄露密码保护： 拒绝出现在已知数据泄露事件中的密码（通过 HaveIBeenPwned 核对）。它适用于 Pro 及以上方案；如果你使用的是 Pro，请开启它。

5. 链接和验证码的有效期 #

魔法链接和一次性验证码在有效期内和密码一样管用。Supabase 建议有效期设为一小时（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 通读一遍：配置自定义 SMTP 后，把邮件上限提高到上线当天所需的水平；其余的除非有理由，否则保持不变。

10. 多因素认证，至少用于管理员 #

如果你的应用有管理后台，或者涉及资金或健康数据，请提供多因素认证（MFA），并要求管理员必须使用。之后，规则可以对敏感表强制要求它：用户的令牌会说明他是否用第二因素登录（aal2）。

这些设置管不了什么 #

Auth 设置决定谁可以登录，但不决定已登录用户能读取和修改什么；那是数据库中 Row Level Security 的职责。如果你还没检查过，先从 10 分钟 RLS 自查开始，再对照上线前安全检查清单检查应用的其余部分。

我们免费的 Security Check 会以只读方式从外部检查你已上线的应用，包括认证配置和数据库规则，并把最严重的问题以书面形式发给你。