Ir al contenido

Ajustes de Supabase Auth que debes revisar antes de lanzar tu app hecha con IA

URLs de redirección, confirmación de correo, SMTP, contraseñas, CAPTCHA: lo que la IA deja por defecto en Supabase Auth y qué cambiar antes de lanzar.

5 min de lectura

Cuando Lovable, Bolt u otra herramienta de IA añade el inicio de sesión a tu app, escribe las pantallas y el código. Los ajustes que deciden lo seguro que es ese inicio de sesión están en otro lugar: en tu proyecto de Supabase, en Authentication, y la mayoría siguen con los valores con los que se creó el proyecto.

Esos valores por defecto están pensados para empezar, no para usuarios reales. Este artículo recorre los ajustes que conviene cambiar antes del lanzamiento, en el orden en que los revisamos. Ninguno requiere código, y la mayoría llevan un minuto.

1. Site URL y URLs de redirección

Después de confirmar un registro, usar un magic link o restablecer la contraseña, Supabase devuelve al usuario a tu app. Site URL es el destino por defecto; Redirect URLs es la lista de las demás direcciones permitidas.

  • Pon en Site URL tu dirección de producción, https://yourapp.com, no http://localhost:3000. Los correos de confirmación y de restablecimiento la usan.
  • En Redirect URLs, incluye las direcciones exactas de producción. Los comodines sirven para el desarrollo local y las previews, pero mantenlos acotados.

2. Confirmación del correo

Con Confirm email desactivado, cualquiera puede registrarse con la dirección de otra persona y usar la cuenta al momento. Actívalo en los ajustes del proveedor de email, salvo que tengas un motivo concreto para no hacerlo, y asegúrate de que la app gestiona el paso de “revisa tu bandeja de entrada”.

3. Tu propio remitente de correo (SMTP)

El servicio de correo integrado de Supabase es para pruebas. Solo envía a miembros de tu organización, y el límite por defecto para los correos de autenticación es de 2 por hora, así que el día del lanzamiento tu segundo usuario nuevo no recibe su correo de confirmación.

Configura un SMTP personalizado con un servicio de envío (Resend, Postmark, Amazon SES, Brevo y otros) en tu propio dominio. Así el correo de confirmación sale de no-reply@yourapp.com y puedes subir los límites de envío. Para que estos correos lleguen a la bandeja de entrada y no a spam, el dominio necesita SPF, DKIM y DMARC, los mismos registros que describimos para los correos del formulario de contacto.

4. Reglas de contraseña

En los ajustes de contraseñas:

  • Longitud mínima: Supabase desaconseja cualquier cosa por debajo de 8 caracteres. Nosotros usamos 10 o más.
  • Caracteres obligatorios: exigir letras y números bloquea las contraseñas más débiles sin mucha fricción.
  • Protección contra contraseñas filtradas: rechaza contraseñas que aparecen en filtraciones de datos conocidas (se comprueban contra HaveIBeenPwned). Está disponible en el plan Pro y superiores; si estás en Pro, actívala.

5. Caducidad de enlaces y códigos

Los magic links y los códigos de un solo uso valen tanto como una contraseña mientras son válidos. Supabase recomienda una caducidad de una hora (3600 segundos) o menos. Si tus usuarios inician sesión con códigos, cuanto más corta, mejor.

6. CAPTCHA en el registro, el inicio de sesión y el restablecimiento de contraseña

Los bots que encuentran tu formulario de registro crean cuentas falsas, gastan tu cuota de correo y prueban contraseñas filtradas en el formulario de inicio de sesión. Supabase Auth admite CAPTCHA con Cloudflare Turnstile o hCaptcha en el registro, el inicio de sesión y el restablecimiento de contraseña: lo activas en el panel (en la protección contra bots y abusos), añades el widget a tus formularios y envías el token con la llamada:

Enviar el token de CAPTCHA con el registro
await supabase.auth.signUp({
  email,
  password,
  options: { captchaToken } // from the Turnstile or hCaptcha widget
});

Turnstile suele ser invisible para los visitantes reales. Una vez activado el CAPTCHA, toda llamada de registro, inicio de sesión y restablecimiento necesita un token, así que actualiza todos los formularios antes de activarlo.

7. Registro y proveedores que no usas

  • Si la app es para un grupo cerrado (un equipo, clientes invitados), desactiva Allow new users to sign up e invita a las personas.
  • Desactiva los proveedores que no usas. Cada proveedor activado es una puerta más.
  • Los inicios de sesión anónimos merecen una revisión aparte. Los usuarios anónimos reciben el rol authenticated, así que una política escrita como “cualquier usuario con sesión iniciada puede leer” también deja entrar a quien solo pulsó “continuar como invitado”. Si usas inicios de sesión anónimos, comprueba el claim is_anonymous en las políticas que importan; si no los usas, mantenlos desactivados.

8. Cambios de correo y de contraseña

Cambiar la dirección de correo o la contraseña es la forma en que una sesión robada se convierte en una cuenta robada. Mantén activado el cambio de correo seguro (el cambio se confirma tanto en la dirección antigua como en la nueva) y, si tu plan y tus ajustes lo permiten, exige un inicio de sesión reciente antes de cambiar la contraseña.

9. Límites de solicitudes

Supabase aplica límites de solicitudes a los registros, los inicios de sesión, las peticiones de códigos y la renovación de tokens. Abre Rate Limits en los ajustes de Auth y léelos una vez: tras configurar el SMTP personalizado, sube el límite de correos a lo que necesite el día del lanzamiento, y deja el resto salvo que tengas un motivo.

10. MFA, al menos para los administradores

Si tu app tiene un área de administración o maneja dinero o datos de salud, ofrece autenticación multifactor y exígela a los administradores. Después, las políticas pueden requerirla para las tablas sensibles: el token del usuario indica si inició sesión con un segundo factor (aal2).

Lo que estos ajustes no hacen

Los ajustes de Auth deciden quién puede iniciar sesión. No deciden qué puede leer y cambiar un usuario con sesión iniciada; eso es tarea de Row Level Security en la base de datos. Si aún no lo has comprobado, empieza por la revisión de RLS en 10 minutos y repasa la lista de seguridad antes del lanzamiento para el resto de la app.

Nuestro Security Check gratuito revisa tu app publicada desde fuera, en modo de solo lectura, incluida la configuración de autenticación y las reglas de la base de datos, y te envía por escrito los problemas más graves.

SupabaseAutenticaciónApps hechas con IALovable

Este artículo también está disponible en: EnglishPortuguês日本語中文