Activar Row-Level Security (RLS) en Supabase es el paso que separa una app de práctica de una app lista para producción. Aquí aprendes qué reglas aplicar en tablas como profiles, posts, likes y comments para que cada usuario solo modifique lo que le pertenece, apoyándote en el asistente con AI que ofrece Supabase.

¿Qué es Row-Level Security y por qué importa en Supabase?

El Row-Level Security, o RLS, es el mecanismo que decide qué usuario puede leer, escribir, actualizar o borrar filas específicas dentro de una tabla. Sin él, cualquier cliente con la clave pública del proyecto podría tocar datos que no debería.

Cuando entras al editor de tablas en el dashboard de Supabase [00:54], notas que cada tabla muestra una etiqueta que dice unrestricted. Al pasar el cursor, la plataforma te avisa que la data está accesible públicamente a través de la API porque el RLS está deshabilitado. Esa es la señal de que tu app todavía no es segura.

¿Qué hace RLS en Supabase? Restringe quién puede leer, escribir o actualizar filas en una tabla. Cuando lo activas, los usuarios anónimos pierden acceso por defecto y solo los usuarios autenticados pueden consumir o modificar el contenido según las políticas que definas.

¿Cómo activar RLS en tablas de Supabase paso a paso?

Tienes dos caminos para habilitarlo. El primero es directo desde la interfaz: aparece un botón que dice deshabilitado y al hacer clic Supabase te explica el efecto antes de confirmar [01:23]. Cuando aceptas, la etiqueta unrestricted desaparece de la tabla y el acceso público queda bloqueado automáticamente.

Una vez activado, llegas al panel de políticas RLS, que puede sentirse abrumador porque mezcla sentencias en SQL con filtros para select, insert, update, delete o all [01:55]. Aquí es donde entra el apoyo del asistente.

¿Dónde está el asistente con AI de Supabase?

En la esquina superior derecha hay un ícono cuadrado verde con un círculo dentro [02:24]. Al abrirlo se despliega un chat potenciado con inteligencia artificial:

• En la versión gratuita usa GPT 5 Mini.
• En la versión pro usa GPT 5.
• Responde consultas sobre tu base de datos y sobre cualquier aspecto de Supabase.

Le puedes pegar una pregunta concreta describiendo qué quieres permitir en cada tabla, y devuelve recomendaciones tabla por tabla más sentencias SQL listas para ejecutar.

¿Qué políticas RLS aplicar en profiles, posts, likes y comments?

La consulta que se le envía al asistente describe reglas claras por tabla [02:55]. La respuesta organiza las políticas así:

• En profiles, cada usuario puede hacer select, update e insert solo sobre su propio perfil.
• En post_new, lectura pública con select sin autenticación, insert solo para autenticados, y update o delete deshabilitados para usuarios normales (pensado para un futuro superadmin).
• En likes, insert y delete solo para el usuario autenticado y sobre su propio like.
• En comments, select público, insert solo autenticado, y update o delete solo por el autor.

Un detalle importante que aporta el asistente es que los likes deben ser únicos por usuario [05:10]. Eso evita que alguien duplique un like y obliga a removerlo en su lugar, una validación que antes vivía solo en el código y ahora queda blindada a nivel de privacidad.

¿RLS reemplaza la validación en el front-end? No del todo. RLS protege la base de datos aunque el cliente sea malicioso, pero la validación en el código sigue mejorando la experiencia. Lo ideal es tener ambas capas trabajando juntas.

¿Cómo crear una política RLS manualmente desde el editor?

Aunque el asistente puede generar un SQL único para ejecutar, advierte que no tiene permiso para leer las tablas del proyecto cuando list table está desactivado [06:15]. Por eso asume nombres y tipos como user_id de tipo uuid referenciando a auth.users, y eso no siempre coincide con tu esquema real.

Por seguridad conviene seguir la recomendación inicial tabla por tabla. Para la tabla comments el flujo es:

1. Entrar a RLS y elegir Crear política.
2. Nombrar la política, por ejemplo security, y permitir select para usuarios anónimos, dejándola como permisiva y pública.
3. Crear una segunda política llamada logged users con insert solo para autenticados.
4. Guardar y verificar que la tabla muestra dos políticas activas [08:35].

Al regresar al listado de tablas, comments ya no aparece como unrestricted y muestra un contador de políticas aplicadas. Ese mismo patrón se replica en profiles, post_new y likes con las recomendaciones que entregó el asistente.

¿Qué ganas al activar RLS en tu PlatziGram?

Proteger las tablas con políticas claras hace que tu versión de PlatziGram sea más segura, estable y lista para producción. Cada usuario solo puede modificar lo suyo, los posts siguen siendo públicos para lectura, y los likes y comentarios respetan la autoría real.

¿Ya activaste RLS en tu proyecto? Cuéntame en los comentarios qué política te costó más configurar y cómo te ayudó el asistente con AI a resolverla.