socorrist.app

403 (Forbidden) en /rest/v1/

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.

Ya de paso: ¿tu app está exponiendo datos?

Analízala gratis mientras lees. Tarda treinta segundos y no toca nada.

Solo leemos lo que tu app ya le entrega a cualquier visitante.

Por qué te pasa

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.

Lo que este error no significa

Arréglalo tú, gratis

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.

  1. 1En Supabase, entra en Authentication y luego Policies, y busca la tabla que da el 403.
  2. 2Mira si tiene alguna política de tipo SELECT. Si no tiene ninguna, ese es el problema y no hay más misterio.
  3. 3Crea una política para SELECT sobre esa tabla y decide a quién abre. Si el contenido es público, como un catálogo, la condición puede permitir a todo el mundo. Si son datos de clientes, la condición debe exigir sesión iniciada, y normalmente además que el identificador del usuario coincida con la columna de propietario de la fila.
  4. 4Si has elegido la opción de propietario, comprueba en el editor de tablas que esa columna está rellena en las filas que ya existían. Las filas creadas antes de añadir la columna suelen tenerla vacía, y ninguna de ellas se verá jamás.
  5. 5Prueba de nuevo desde la app, con sesión iniciada si la política la exige. Si funciona con sesión y falla sin ella, todo está bien: lo que falla entonces es el momento en que tu app pregunta, y eso va en el prompt de abajo.

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.

Y esto para la parte de código

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 pegarle a 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.

¿Lo has intentado y sigue sin salir?

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.

Cita a partir de mañana

Agendar revisión

99 €

Elegimos hueco, miro tu app con calma y te digo qué pasa y cómo se arregla.

  • Sesión de trabajo en directo contigo
  • Diagnóstico del error y del riesgo real
  • Te quedas con el arreglo aplicado
Ver huecos disponibles

Hoy, en cola prioritaria

Rescate exprés

199 €

Entras en la cola de hoy. Reservas hueco y lo dejamos resuelto en el día.

  • Hueco el mismo día
  • Prioridad sobre las revisiones agendadas
  • Mismo trabajo, antes
Ver huecos de hoy

Quién lo arregla

Marc Sala

IT Manager

  • Analista de ciberseguridad certificado por Google

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.

Errores que suelen venir con este