Sin reglas de seguridad, cualquiera podría acceder a tus datos directamente. Supabase tiene un sistema llamado RLS que actúa como portero de tu base de datos — tú decides quién puede ver qué.

Hasta ahora hemos aprendido que Supabase guarda datos en tablas, autentica usuarios y almacena archivos. Pero hay una pregunta fundamental que aún no hemos respondido: ¿cómo decides quién puede ver qué? Eso es exactamente lo que hace la seguridad en Supabase.

El problema sin seguridad

Imagina que tienes una aplicación con fotos privadas de un evento. La base de datos tiene todos los datos. Pero si no hay reglas de seguridad, cualquier persona podría intentar leer datos que no debería: fotos, nombres, mensajes o información privada.

¿Cómo? A través de la API — que es básicamente una puerta de entrada para comunicarse con tu base de datos. Cada proyecto de Supabase tiene una dirección pública con un formato como este: https://sdndwseilatdqjksfoqx.supabase.co

Esa dirección es como la dirección de un banco: todo el mundo sabe dónde está, y eso no es un problema. El código de cualquier app web es visible desde el navegador — cualquiera puede verlo con clic derecho y «Ver código fuente». Supabase lo diseña así a propósito, porque la protección no viene de esconder la dirección, sino de las reglas que controlan qué puede hacer cada persona cuando llega a ella. Sin esas reglas, sería como un banco sin puertas blindadas ni cajas fuertes.

Es como construir una casa sin cerraduras. La casa existe, está bien construida, pero cualquiera podría intentar entrar.

Qué son las políticas de seguridad

Supabase tiene un sistema llamado RLS (Row Level Security, o seguridad a nivel de fila). Es una forma de decirle a la base de datos exactamente quién puede hacer qué.

Puedes crear reglas como:

  • Solo los usuarios que han iniciado sesión pueden ver ciertas fotos
  • Cada usuario solo puede ver sus propios datos, no los de los demás
  • Solo el administrador puede borrar contenido
  • Cualquiera puede leer el catálogo, pero solo los clientes registrados pueden comprar

Estas reglas viven directamente en la base de datos, no solo en la app. Eso significa que aunque alguien intente saltarse tu aplicación y conectarse a Supabase directamente, las reglas siguen funcionando.

Dos roles habituales en Supabase

En una aplicación normal, vas a encontrarte sobre todo con dos roles:

  • anon — usuario anónimo, sin cuenta o sin sesión válida. Es cualquier persona que llega a tu app sin identificarse.
  • authenticated — usuario que ha iniciado sesión. Supabase recibe una sesión válida y puede aplicar reglas según ese usuario.

La mayoría de los errores de seguridad ocurren cuando se dan permisos a anon sin darse cuenta, creyendo que si la app controla el acceso, Supabase no necesita hacerlo. Pero si la base de datos no tiene sus propias reglas, alguien podría saltarse la app y consultar datos directamente desde esa dirección pública que vimos antes.

Las políticas: las cerraduras de tu base de datos

Cada tabla puede tener sus propias políticas, y Storage también se protege con políticas sobre los archivos guardados. Hay cuatro tipos de acción que puedes controlar:

  • SELECT — ver datos
  • INSERT — añadir datos nuevos
  • UPDATE — modificar datos existentes
  • DELETE — borrar datos

Para cada acción decides: ¿quién puede hacerla? ¿Solo usuarios autenticados? ¿Solo el propio usuario dueño del dato? ¿Solo el admin? Tú decides.

Un ejemplo real

Imagina una app para compartir fotos de eventos privados, como MiraMiEvento. Las reglas de seguridad correctas podrían ser:

  • Las fotos solo las puede ver quien tiene una sesión válida o permisos válidos para ese evento
  • Las fotos solo las puede subir el organizador del evento
  • Nadie puede borrar fotos de otros
  • Los usuarios anon no pueden ver ni subir contenido privado

Con estas políticas, aunque alguien encuentre la dirección de Supabase e intente acceder directamente, recibirá un error de acceso denegado si no tiene permisos. La base de datos misma actúa como portero.

La lección más importante

La seguridad no es algo que se añade al final cuando la app ya está lista. Es algo que se diseña desde el principio, antes de escribir la primera línea de código.

Una buena regla general: empieza con todo cerrado y abre solo lo necesario. Es mucho más seguro que abrir todo al principio y recordar cerrarlo después.

Qué hemos aprendido en este módulo

  • Sin políticas de seguridad, alguien podría acceder a tus datos directamente desde la dirección pública de Supabase.
  • Esa dirección es pública y visible — la protección viene de las reglas RLS, no de esconderla.
  • RLS (Row Level Security) permite definir reglas exactas de quién puede hacer qué.
  • En Supabase vas a encontrarte a menudo con los roles anon y authenticated.
  • Las políticas viven en la base de datos, no dependen solo de la app para funcionar.
  • La seguridad se diseña desde el principio, no se parchea al final.

En el próximo módulo veremos cómo todo lo que hemos aprendido — tablas, autenticación, Storage y seguridad — se conecta para construir una aplicación real de principio a fin.

Fuentes

  • Row Level Security | Supabase Docs — documenta cómo funciona RLS en PostgreSQL: políticas por tabla, roles anon y authenticated, y tipos de acción (SELECT, INSERT, UPDATE, DELETE).
  • Securing your API | Supabase Docs — explica por qué la URL pública de Supabase no es un problema de seguridad y cómo las políticas RLS protegen los datos aunque alguien acceda directamente.
  • Storage Access Control | Supabase Docs — muestra cómo las políticas de seguridad se aplican también sobre los archivos en Storage, no solo sobre las tablas.