Política USING (true): acceso abierto a todo

Tu tabla tiene la seguridad por filas activada, así que el panel de Supabase la da por protegida. Pero la política que la gobierna dice, literalmente, que la condición para acceder es verdadera. O sea: que sí, siempre, a quien sea.

Compruébalo en tu app ahora, gratis

Esto no da la cara solo: tu app funciona igual de bien esté abierta o cerrada. La única forma de saberlo es mirar.

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

Por qué te pasa

Porque es la única respuesta que hace desaparecer el error a la primera. Cuando salta un fallo de permisos, hay dos caminos: pensar quién debe tener acceso y escribir la condición, o poner una condición que siempre se cumple. La segunda funciona siempre, al instante y sin entender nada del problema. Es lo que suele salir cuando se le pide a un agente que arregle un error de RLS sin más contexto.

También viene de los ejemplos. Media documentación y medio tutorial usan esta política para ilustrar cómo se escribe una, porque es la más corta. En una tabla de contenido público es perfectamente correcta. Copiada tal cual en una tabla de clientes, la deja abierta.

Lo que hace esto peor que no tener seguridad activada es la falsa sensación de orden. Una tabla sin proteger aparece marcada en el panel de Supabase y salta a la vista. Una tabla con esta política aparece como protegida, con su candado y su política escrita, y no la mira nadie más. Está igual de abierta y además nadie la audita.

Lo que este error no significa

No significa que tengas que desconfiar de todas tus políticas. Significa que hay que leerlas, que es distinto. Muchas estarán bien escritas.
No significa que esta política esté mal siempre. En una tabla de precios públicos, de artículos de un blog o de un catálogo, permitir la lectura a cualquiera es exactamente lo que quieres. El problema es solo cuando la tabla tiene datos de personas.
No es un fallo de Supabase ni de la herramienta con la que hiciste la app. Es una decisión de configuración que se tomó por ti, en un momento en que lo urgente era que dejara de dar error.

Arréglalo tú, gratis

Se revisa en el panel y se arregla en el panel. Lo único que necesitas traer de casa es la respuesta a una pregunta por tabla: quién debería poder ver esto.

1En Supabase, ve a Authentication y luego Policies. Verás todas las políticas agrupadas por tabla, con su condición a la vista.
2Busca las que tengan como condición la palabra true, sola. Repásalas todas: también las de inserción, actualización y borrado, no solo las de lectura. Una política de borrado abierta es bastante peor que una de lectura.
3Por cada una, mira qué contiene esa tabla en el editor de datos. Si hay correos, nombres, pedidos, mensajes o cualquier cosa que identifique a una persona, esa política hay que cambiarla.
4Sustituye la condición por la que corresponda. Para datos que solo debe ver su dueño, la condición compara el identificador del usuario de la sesión con la columna de propietario de la fila. Para datos que ve cualquier usuario registrado pero no el público general, basta con exigir que haya sesión iniciada.
5Guarda y prueba la app entera, no solo la pantalla que estabas mirando. Un cambio de política afecta a todos los sitios donde se lea esa tabla.
6Comprueba que ha funcionado desde fuera: abre tu app en una ventana de incógnito, sin iniciar sesión, y mira si esa pantalla sigue enseñando datos. Si los enseña, la política no se ha aplicado o hay otra por debajo permitiéndolo.

Cuidado con las columnas de propietario vacías. Si añadiste esa columna después de tener filas creadas, las antiguas la tienen a nulo y no coincidirán con nadie: dejarán de verse. Eso no es un fallo de la política, es que hay que rellenarlas.

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

En mi proyecto de Supabase hay políticas de seguridad por filas con la condición puesta a true, que dejan pasar a cualquiera.

Necesito que hagas esto:
1. Dime, por cada tabla que use la app, qué datos contiene y si esos datos pertenecen a un usuario concreto o son públicos.
2. Para las tablas con datos de personas, escríbeme en SQL la política que debería sustituir a la abierta, separada por operación (lectura, inserción, modificación, borrado), con un comentario que diga a quién deja hacer qué.
3. Comprueba que el código rellena siempre la columna de propietario al crear filas nuevas. Si no lo hace, corrígelo, porque si no las políticas nuevas dejarán fuera todo lo que se cree a partir de ahora.
4. Dime si alguna pantalla de la app depende de leer datos de otros usuarios. Si la hay, quiero saberlo antes de cerrar nada, porque esa pantalla dejará de funcionar y hay que decidir qué hacemos con ella.

No apliques nada en la base de datos: dame el SQL para que lo revise yo.

Si el escáner ha encontrado algo, no lo toques con prisa

Cerrar una puerta abierta tiene un orden: primero se corta el acceso, después se comprueba en los registros si alguien entró, y solo entonces se despliega. Hacerlo al revés deja la app caída y borra el rastro de lo que pasó. Si prefieres no hacerlo solo, elige cuándo lo hacemos.

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.