Lovable error forbidden (403): por qué pasa y qué hacer

El error “forbidden” (código 403) en Lovable significa que la petición llegó bien, pero no tienes permiso para hacer esa acción. Puede venir del propio Lovable (no tienes acceso al proyecto, al workspace o a esa función) o de tu app publicada (las reglas de tu base de datos o una función rechazan al usuario). Primero identifica dónde aparece, porque la solución es diferente.

Paso 1: ¿dónde ves el error?

Dónde aparece	Origen probable
Al abrir o editar un proyecto en lovable.dev	Permisos en Lovable (workspace, rol, invitación)
Al hacer remix o copiar un proyecto ajeno	El dueño lo tiene privado o con remix desactivado
En tu app publicada, al guardar o leer datos	Reglas de la base de datos (RLS de Supabase)
En tu app publicada, al llamar una función	La función exige sesión o un rol que el usuario no tiene

Caso 1: forbidden dentro de Lovable

Te invitaron y no puedes entrar

1. Revisa con qué correo iniciaste sesión (esquina de tu perfil). La invitación debe ser a ese mismo correo. Si entraste con Google y la invitación llegó a otro correo, no coinciden.
2. Revisa en el selector de workspace que estés en el que contiene el proyecto. Lovable indica que no puede acceder a proyectos fuera de tu workspace actual.
3. Pide al dueño que revise tu rol: algunos roles pueden ver pero no editar, y solo dueños o administradores manejan configuraciones como dominios o GitHub.

Quieres hacer remix de un proyecto

Si el dueño desactivó el remix o el proyecto es privado, recibirás un rechazo. No hay forma de saltarlo: pídele al dueño que lo habilite o que te comparta el proyecto.

Acciones de configuración (dominios, GitHub, facturación)

Funciones como conectar GitHub o un dominio requieren rol de owner o admin del workspace, y algunas requieren plan de pago. Si eres editor, pide al dueño que lo haga o que te cambie el rol. Ver cómo conectar Lovable a GitHub.

Caso 2: forbidden en tu app publicada

Aquí Lovable no tiene la culpa: es tu backend protegiendo los datos (o protegiéndolos de más).

Paso a paso

1. En tu app: clic derecho → Inspeccionar → Network. Repite la acción y busca la fila en rojo.
2. Mira la URL:
   • Contiene /rest/v1/ → es la base de datos de Supabase.
   • Contiene /functions/v1/ → es una Edge Function.
   • Contiene /storage/v1/ → es el almacenamiento de archivos.
3. Lee la respuesta (pestaña Response). Mensajes típicos:
   • permission denied for table ... → falta permiso o política.
   • new row violates row-level security policy → RLS bloqueó una inserción. Ver este post.

Revisa las políticas RLS

RLS (Row Level Security) son reglas que deciden qué filas puede leer o escribir cada usuario. Si una tabla tiene RLS activado y ninguna política que permita la acción, Supabase la rechaza. En el panel de Supabase: Authentication → Policies (o Database → Tables → tu tabla → Policies, según la versión del panel).

Ejemplo de una política correcta para que cada usuario lea solo sus pedidos:

create policy "Usuarios leen sus pedidos"
on public.pedidos
for select
to authenticated
using ( (select auth.uid()) = user_id );

Más ejemplos en políticas RLS de Supabase.

Revisa la sesión del usuario

Muchas veces el 403 aparece porque el usuario no tiene sesión (expiró, o la app manda la petición antes de terminar el login). Prueba cerrando sesión y volviendo a entrar. Si así funciona, el problema es de tiempo en el código: la app pide datos antes de tener la sesión lista.

Si falla al subir archivos

Cuando la URL contiene /storage/v1/, el rechazo viene de las políticas de Storage, que son independientes de las de tus tablas. Un patrón habitual es que cada usuario solo pueda subir a una carpeta con su propio ID:

create policy "Usuarios suben a su carpeta"
on storage.objects
for insert
to authenticated
with check (
  bucket_id = 'documentos'
  and (storage.foldername(name))[1] = (select auth.uid()::text)
);

Si tu app sube el archivo a una ruta como documentos/foto.png (sin el ID del usuario al inicio), esta política lo rechaza aunque el usuario tenga sesión. El arreglo está en la ruta que arma el código, no en abrir la política. La guía oficial está en supabase.com/docs/guides/storage.

Cómo pedirle a Lovable que lo arregle sin abrir tu base

El chat de Lovable a veces “resuelve” un 403 quitando la protección. Para evitarlo, sé explícito en tu mensaje:

Al guardar un pedido aparece 403 en /rest/v1/pedidos. No desactives RLS ni uses using (true). Agrega una política de insert para que un usuario autenticado solo pueda crear pedidos con su propio user_id, y muéstrame el SQL antes de aplicarlo.

Después de cada cambio, prueba con dos cuentas distintas: la segunda no debe ver los datos de la primera.

Lo que NO debes hacer

• Desactivar RLS para que desaparezca el error. Deja tu tabla abierta a cualquiera con la llave pública. En mayo de 2025, la vulnerabilidad CVE-2025-48757 documentó que 170 de 1,645 apps de la vitrina de Lovable dejaban leer o escribir tablas así.
• Usar la llave service_role en el frontend. Salta todas las reglas, y si se filtra, cualquiera controla tu base de datos. Ver service role key expuesta.
• Crear políticas using (true) para todo.

Errores comunes

• Probar como administrador y no como un usuario normal.
• Crear la política para select pero no para insert o update.
• Olvidar que el almacenamiento (Storage) tiene sus propias políticas.

Si tu app publicada rechaza a usuarios que sí deberían entrar, o no sabes si tus políticas están bien, en Black Engine revisamos tus reglas de Supabase contigo por WhatsApp para que funcione sin dejar los datos abiertos. Para entender el tema a fondo, lee qué es RLS en Supabase.