Row-Level Security en Supabase paso a paso

Proteger datos en Supabase exige aplicar row-level security (RLS) con políticas claras para cada tabla. Aquí verás cómo habilitarlo, qué reglas configurar en profiles, posts_new, likes y comments, y cómo apoyarte en el asistente con AI de Supabase para generar SQL útil sin exponer tu app.

¿Por qué row-level security en Supabase protege tu app?

Activar RLS determina quién puede leer, escribir, actualizar o borrar filas específicas. Sin RLS, cualquier cliente con la clave pública podría modificar datos sensibles. Al habilitarlo, el acceso por defecto se bloquea: solo usuarios logueados pueden operar y, si necesitas lectura pública, debes crear políticas explícitas.

• Evita modificaciones indebidas con clave pública.
• Aísla datos por usuario como en una red social.
• Obliga a definir políticas de acceso: select, insert, update, delete.
• Mejora la seguridad antes de ir a producción.

¿Cómo activar RLS y crear políticas en las tablas clave?

En el dashboard de Supabase, cada tabla muestra si está “unrestricted”. Al activar RLS, todo acceso público queda bloqueado hasta definir políticas. El panel de políticas incluye filtros por acción y sentencias SQL. Es normal que parezca denso: puedes apoyarte en el asistente con AI y luego aplicar manualmente.

¿Qué políticas aplicar en profiles para seguridad por usuario?

• Select, insert y update solo sobre el propio perfil.
• Requiere usuario autenticado para operar.
• Garantiza que nadie edite perfiles ajenos.

¿Qué reglas necesita posts_new para lectura pública e insert seguro?

• Lectura pública: permitir select sin autenticación para listar posts.
• Insert solo para usuarios autenticados.
• Update y delete no permitidos a usuarios normales.
• Se puede ajustar después si requieres un rol tipo super admin.

¿Cómo controlar likes y comments con permisos claros?

• Likes.
  • Insert y delete solo por el usuario autenticado sobre su propio like.
  • Like único por usuario: evita duplicados a nivel de base, no solo en código.
• Comments.
  • Select público: lectura abierta para todos.
  • Insert solo para autenticados.
  • Update y delete solo por el autor.
• Ejecución manual en comments:
  • Crear política para select público (anónimos).
  • Crear política para insert de autenticados.
  • Resolver errores de nombre duplicado cambiando el nombre de la política.
  • Verificación: la tabla muestra dos políticas activas.

¿Cómo ayuda el asistente con AI de Supabase a generar SQL?

El icono superior derecho abre un chat potenciado con AI (en plan gratuito, GPT-5 mini; en pro, GPT-5). Puedes pedirle: “qué opciones marcar en RLS para…”, y devuelve un resumen por tabla y scripts SQL listos para ejecutar.

• Entrega recomendaciones por tabla: profiles, posts_new, likes, comments.
• Genera SQL para habilitar RLS: alter table ... enable row-level security.
• Proporciona políticas con comentarios y notas de uso.
• Advierte supuestos: schema public, columnas relacionadas al usuario como user ID tipo UUID.
• Si tus nombres o tipos difieren, ajusta el SQL antes de ejecutar.
• Si no puede listar tablas, sugiere un script único “asumido” y recomienda validar.
• Buen flujo: copiar recomendaciones iniciales y aplicarlas manualmente en el editor.

Habilidades y conceptos reforzados:

• Definir lectura pública con select para anónimos cuando convenga.
• Restringir insert/update/delete a usuarios autenticados o al autor.
• Entender políticas permisivas y su alcance por acción.
• Diagnosticar errores comunes de políticas (nombres repetidos) y corregirlos.
• Considerar el impacto en el front end: sin políticas de lectura, los listados fallan; para publicar, se requiere sesión.

¿Te quedó alguna duda sobre qué política aplicar en tu caso? Comenta tu esquema y nombres de columnas para ajustar las reglas y el SQL con precisión.