db
Supabase ha entendido la petición y sabe quién la hace. Simplemente ha decidido que quien la hace no tiene permiso para ver eso. Si además ves un mensaje que dice permission denied for table, es exactamente lo mismo dicho con otras palabras.
Revisado en agosto de 2026
De paso
Analízala gratis mientras lees. Tarda treinta segundos y no toca nada.
Solo leemos lo que tu app ya le entrega a cualquier visitante.
Diagnóstico
La seguridad por filas de Supabase funciona al revés de lo que uno espera: al activarla en una tabla, esa tabla queda cerrada del todo, y solo se abre para lo que autorices explícitamente con una política. Sin política, la respuesta por defecto es que no. Un 403 en lectura casi siempre significa que la tabla tiene la seguridad activada y ninguna política que permita leerla.
El segundo caso es que la política exista pero no encaje con quien pregunta. Es muy típico haberla escrito para usuarios identificados y que la petición salga sin sesión: porque el visitante no ha iniciado sesión, porque la sesión ha caducado, o porque la llamada ocurre al cargar la página, antes de que la app haya terminado de recuperar la sesión guardada.
El tercero es más sutil: la política dice que cada usuario ve sus propias filas comparando su identificador con una columna de la tabla, pero esa columna está vacía en las filas antiguas. Nadie coincide con un valor nulo, así que no se ve nada aunque la sesión sea correcta.
Solución
Se resuelve en el panel de Supabase. Antes de tocar nada, ten claro quién debe poder ver esa tabla: es la única decisión de fondo, y el resto son dos clics.
No confundas este 403 con un 401. El 401 dice que no sabe quién eres; el 403 dice que sí lo sabe y aun así no te deja. Son arreglos distintos.
Pégaselo tal cual al agente que escribió tu app. Está redactado para que te diga lo que ha hecho, no solo para que lo haga.
Prompt para tu agente
Mi app recibe un 403 al leer datos de Supabase en /rest/v1/. Sospecho que es por las políticas de seguridad por filas. Necesito que hagas esto: 1. Localiza la consulta que falla y dime qué tabla lee, en qué momento del ciclo de vida de la app se lanza y si en ese momento hay sesión de usuario garantizada. 2. Si la consulta se lanza al cargar la página, antes de que la sesión esté restaurada, cámbiala para que espere a que la sesión esté lista antes de pedir nada. 3. Distingue en el código el caso de no tener permiso del caso de no haber datos, y muestra al usuario un mensaje distinto en cada uno. Ahora mismo probablemente los dos acaban en una pantalla vacía. 4. Escríbeme en SQL la política de SELECT que necesitaría esa tabla, para que yo la revise antes de aplicarla en el panel, y explícame en una línea a quién deja leer. Muy importante: no desactives la seguridad por filas, no escribas una política que permita leer a cualquiera si la tabla tiene datos de clientes, y no uses la clave service_role en el navegador para saltarte esto.
Si no sale
O el escáner de arriba ha encontrado algo y prefieres no tocarlo solo. En cualquiera de los dos casos esto ya es de los gordos y merece un humano: no es que no hayas sabido, es que has llegado al punto en que hace falta alguien que entre y lo vea por dentro.
Las 10 primeras apps son gratis. Estoy empezando y necesito casos reales. A cambio te pido permiso para contar después qué me encontré, sin decir de quién era la app ni enseñar tus datos. Sin tarjeta y sin suscripción: cuando se acaben las plazas empezaré a cobrar y lo diré aquí.
Cita a partir de mañana
Gratis
durante el lanzamiento
Elegimos hueco, miro tu app con calma y te digo qué pasa y cómo se arregla.
Hoy, en cola prioritaria
Gratis
durante el lanzamiento
Entras en la cola de hoy. Reservas hueco y lo dejamos resuelto en el día.
Quién
Marc Sala
IT Manager
No es un rating anónimo de un marketplace: es la persona que va a entrar en tu app. Reviso el código, encuentro qué falla y lo arreglo contigo delante, explicándote qué ha pasado sin jerga.
Relacionados