La llave pública no es el problema
Una app de AI Studio con Supabase lleva la llave anon dentro del código que baja al navegador. Eso es normal y por diseño en Supabase: esa llave es pública y está hecha para exponerse. No la "arregles" escondiéndola.
Lo que sí es un problema
En una app real que revisamos, el rol del usuario (administrador, empleado) se leía de localStorage, es decir, del propio navegador. Cualquiera abre la consola y escribe una línea para convertirse en administrador. Un rol que vive en el navegador no es control de acceso: es una sugerencia.
La combinación peligrosa tiene tres piezas:
- La llave anon va en el código (normal).
- El rol se puede falsificar en el navegador.
- RLS apagado en la tabla.
Con las tres, cualquier persona con la URL puede leer la tabla completa desde la consola. Si esa tabla guarda datos de clientes, pacientes o pagos, no es un riesgo teórico: es una filtración.
La prueba de cinco minutos
- En el panel de Supabase abre Table Editor y mira cada tabla. Debe decir RLS enabled. Si dice "unrestricted", está abierta.
- En el navegador, abre la app, las herramientas de desarrollo y la pestaña de almacenamiento local. Si ves una clave con el rol ("role", "admin") que la app usa para decidir qué mostrar, el control está en el lugar equivocado.
- Revisa si la app usa Supabase Auth de verdad (inicio de sesión con correo y contraseña) o solo una pantalla de login decorativa.
Cómo se arregla
- El rol viaja con el usuario, no con el navegador. Guárdalo en una tabla de usuarios y léelo del servidor.
- Activa RLS en cada tabla y escribe políticas atadas al usuario que inició sesión. Un ejemplo mínimo:
alter table pedidos enable row level security;
create policy "cada quien ve lo suyo"
on pedidos for select
using (auth.uid() = usuario_id);
- Pide la seguridad en el prompt. AI Studio inventa o descuida lo que el prompt no fija. Dile explícitamente: autenticación con Supabase Auth, rol en la base de datos y RLS en todas las tablas.
Datos regulados
Si la app guarda datos de salud, la responsabilidad es del dueño del negocio, no de la herramienta. En Estados Unidos aplica HIPAA. HighLevel lo dice en su propia página: no es compatible con HIPAA por defecto. Hay que comprar y activar su módulo HIPAA (US$297 al mes o US$2.970 al año, según esa página, consultada el 2 de octubre de 2026), firmar el acuerdo BAA dentro de la app y asumir que la responsabilidad final es de tu organización. Y todo eso cubre HighLevel, no la base de datos externa que AI Studio conecte: una app con Supabase necesita su propio cumplimiento. En República Dominicana, los datos de salud son sensibles bajo la Ley 172-13.
Una regla ética para auditar
No consultes la tabla protegida de un tercero para "demostrar" que está abierta. Si los datos son de pacientes o clientes reales, mirarlos ya es el daño. Confirma el riesgo por la estructura (de dónde sale el rol, qué llave lleva, qué tablas existen) y avisa al dueño. Una prueba en vivo solo se hace en un proyecto tuyo o con autorización del dueño.