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
Tengo tablas sin RLS: cualquiera puede leerlas
En Supabase, la clave pública de tu app va en el navegador a propósito, y cualquiera puede leerla. Lo que impide que esa clave sirva para descargarse tus tablas enteras son las políticas de seguridad por filas. Si una tabla no las tiene activadas, esa protección no existe y la tabla está abierta a quien pregunte.
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 activarla rompe cosas y desactivarla las arregla al instante. Cuando un agente se encuentra con un error de permisos al guardar o al leer, la solución que hace desaparecer el error en un segundo es quitar la seguridad de esa tabla. La app empieza a funcionar, nadie vuelve a mirar, y la tabla se queda así.
También pasa sin que nadie decida nada. Las tablas creadas directamente con SQL no llevan la seguridad activada por defecto: hay que acordarse de activarla. Si tus tablas las creó un agente escribiendo SQL en vez de usando el panel, es muy probable que varias estén así.
Lo que lo hace difícil de detectar es que no se comporta como un fallo. La app funciona perfectamente, no hay ningún error, ningún log raro y ninguna alerta. Supabase lo señala en su panel con una marca en las tablas sin restricción, pero si nadie entra a mirar esa pantalla, nadie se entera.
Lo que este error no significa
- No significa que tus datos ya estén circulando por ahí. Significa que se pueden pedir. Es la diferencia entre tener la puerta abierta y que hayan entrado, y esa diferencia se comprueba en los registros de tu proyecto, no se adivina.
- No es culpa de que la clave pública esté a la vista. Esa clave está pensada para ser pública y en una tabla bien protegida no sirve para leer nada que no le corresponda. El problema no es que la llave se vea: es que esa puerta no tiene cerradura.
- No significa que tengas que cerrarlo todo. Hay tablas que deben ser públicas, como un catálogo o una lista de precios. La pregunta no es si activar la seguridad, que sí, sino qué política le pones a cada tabla.
Arréglalo tú, gratis
El riesgo real de este arreglo no es la seguridad, es dejar la app tirada: activar la seguridad en una tabla sin ponerle una política la cierra a cal y canto, también para tu propia app. Por eso se hace tabla por tabla y con la política preparada antes de pulsar el botón.
- 1En Supabase, entra en el editor de tablas y repasa la lista. Las que están sin proteger aparecen marcadas como sin restricción. Apúntalas todas antes de tocar ninguna.
- 2Clasifícalas en dos montones, y esta es la única decisión de verdad: las que contienen datos de personas y las que contienen información que da igual que vea cualquiera.
- 3Empieza por una tabla del primer montón que sepas que tu app solo lee, no escribe. Es la más fácil de probar y la que menos ruido hace si te equivocas.
- 4Ve a Authentication y luego Policies, crea primero la política de lectura para esa tabla, y solo después activa la seguridad por filas. En ese orden la app no llega a quedarse sin acceso ni un segundo.
- 5Prueba la app de inmediato: entra como usuario normal y comprueba que esa pantalla sigue viéndose. Si se ha quedado vacía, la política no encaja con cómo pregunta tu app, y el prompt de abajo sirve para averiguar por qué.
- 6Repite con el resto, de una en una y probando entre medias. Es lento a propósito: hacerlo todo de golpe y descubrir que la app no va es cómo se acaba desactivándolo todo otra vez.
Las tablas del segundo montón también necesitan la seguridad activada, con una política de solo lectura para todo el mundo. Una tabla pública protegida sigue impidiendo que alguien la modifique; una tabla pública sin proteger, no.
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
Tengo tablas en Supabase sin seguridad por filas activada y quiero cerrarlas sin romper la app. Necesito que hagas esto: 1. Recorre el código y hazme un inventario: qué tablas usa la app, y para cada una si solo lee, si escribe, y desde qué pantallas. 2. Dime en cuáles de esas operaciones hay un usuario identificado garantizado y en cuáles la app pregunta sin sesión. 3. Para cada tabla, escríbeme en SQL las políticas que necesitaría, separadas por operación, con un comentario en una línea explicando a quién deja hacer qué. No las apliques: quiero revisarlas antes de ponerlas en el panel. 4. Si alguna tabla tiene datos de personas pero la app la consulta sin sesión, dímelo de forma destacada: eso significa que la app está dando por hecho un acceso público que no debería existir, y hay que cambiar cómo pregunta. No propongas desactivar la seguridad en ningún caso, y no uses la clave service_role para esquivar esto.
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.
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
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
- Política USING (true): acceso abierto a todoTu 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.
- 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.
- La clave service_role de Supabase está en el código públicoSupabase te da dos llaves. Una es pública y va en el navegador a propósito. La otra, la service_role, se salta todas las reglas de seguridad de tu base de datos y solo debe vivir en un servidor. La segunda ha acabado dentro del código que se descarga cualquiera que visite tu web.