Cómo proteger el panel de administración de tu app

Un panel de administración seguro es uno donde cada acción de admin se autoriza en el servidor o en la base de datos, según un rol que el usuario no puede cambiarse solo, y donde las cuentas de administrador necesitan un segundo factor para entrar. Esconder la página, usar una URL difícil de adivinar o revisar un isAdmin en el navegador no protege nada, porque los datos y las acciones detrás de esa página siguen accesibles directamente. Suma un registro de las acciones de admin y dale a cada persona solo el acceso que su trabajo necesita.

En esta guía verás dónde debe vivir el rol, cómo aplicarlo en Supabase o en un backend propio, por qué los administradores necesitan doble factor, qué registrar y una lista corta para revisar el panel que ya tienes.

¿Por qué el panel de admin es un punto débil tan común?

Porque tiene el mayor poder y recibe la menor cantidad de pruebas. Los usuarios normales recorren todas las pantallas de la app; el panel lo usan una o dos personas que ya tienen acceso, así que nadie nota cuando su protección es solo de apariencia.

En apps hechas con Lovable, Bolt, Cursor y herramientas parecidas, los patrones habituales son:

• La ruta de admin no aparece en el menú, pero cualquiera con sesión puede abrir /admin directamente.
• La página revisa el rol en React (if (user.role === 'admin')), mientras las tablas que lee están abiertas a cualquier usuario con sesión.
• El rol se guarda donde el usuario puede editarlo, como su propia fila de perfil o el user_metadata de Supabase.
• Las acciones de admin llaman a la base de datos con la clave secreta (service_role) desde el navegador, o sea que esa clave es pública.

¿Dónde se guarda el rol de administrador?

En un lugar que solo tu servidor pueda escribir. En Supabase tienes dos opciones sólidas.

La documentación de Supabase advierte que el usuario con sesión puede modificar su user_metadata, y que no debe usarse en políticas de seguridad. Asigna app_metadata desde una función de servidor:

// Solo en el servidor, con la clave secreta
await supabaseAdmin.auth.admin.updateUserById(userId, {
  app_metadata: { role: 'admin' },
});

El rol aparece en el token del usuario cuando su sesión se renueva. Si necesitas que un cambio o una baja de rol se apliquen al instante, conviene una tabla de roles que lean tus políticas.

¿Cómo aplico el acceso de admin en la base de datos?

Cada tabla que el panel lee o modifica necesita una política que permita explícitamente el rol de admin, aparte de las políticas para usuarios normales. Con el rol guardado en app_metadata:

create policy "Admins can read all orders"
on public.orders for select
to authenticated
using ((select auth.jwt() -> 'app_metadata' ->> 'role') = 'admin');

Agrega políticas equivalentes para las modificaciones y borrados que los admins de verdad necesitan, y nada más. Si hacen falta operaciones masivas o datos que las políticas normales no deberían tocar, ponlas en funciones de servidor que primero verifiquen el rol de quien llama y solo después usen la clave secreta. Nuestra guía de roles de usuario y panel admin en Bolt muestra la configuración completa paso a paso.

En un backend propio la regla es la misma: un middleware que lee el rol de la sesión verificada y rechaza la petición antes de que corra cualquier acción de admin.

¿Los administradores deberían usar doble factor?

Sí. La cuenta de admin es la más valiosa de tu app, y una contraseña reutilizada o robada con phishing es la forma más común de entrar. Supabase Auth permite factores TOTP (app de autenticación) en todos los proyectos, y puedes exigir el segundo factor desde la base de datos con una política restrictiva que revise el nivel de verificación del token:

create policy "Admin tables need MFA"
on public.orders
as restrictive
to authenticated
using ((select auth.jwt() ->> 'aal') = 'aal2');

Una política restrictiva como esta aplica a todos los que lleguen a la tabla; si los usuarios normales también la leen, limítala a los admins o separa los datos de admin en sus propias tablas. En autenticación de dos factores en tu app explicamos el registro del factor y la recuperación.

¿Qué debe registrar el panel de admin?

Lo suficiente para responder después "quién hizo qué, sobre qué registro y cuándo". Como mínimo:

• Inicios de sesión de cuentas de admin, incluidos los fallidos.
• Cambios de rol, borrado de cuentas, reembolsos, cambios de plan y exportaciones de datos.
• Cada vez que un admin ve o actúa "como" otro usuario.

Guárdalo en una tabla donde los admins puedan insertar pero no editar ni borrar, o en un servicio externo de registros. Revísalo de vez en cuando y pon una alerta para eventos raros, como la creación de un admin nuevo. En monitoreo y errores en producción sugerimos herramientas simples.

¿Cómo aplico el mínimo privilegio?

No todos los que usan el panel necesitan todo lo que tiene.

1. Divide el rol según lo que la gente realmente hace: soporte (ver cuentas, reenviar correos), cobros (reembolsos), dueño (todo, incluidos los roles).
2. Deja las acciones peligrosas (borrar usuarios, exportar todos los datos, cambiar roles) en el grupo más chico posible.
3. Pide confirmación, o una segunda persona, para las acciones irreversibles.
4. Quita el acceso el mismo día en que alguien se va o un contratista termina. Lleva una lista de quién es admin y revísala cada pocos meses.
5. Nunca compartas un mismo login de admin entre varias personas; las cuentas individuales son las que hacen útil el registro.

¿Cómo reviso el panel que ya tengo?

Una prueba corta que puedes hacer tú:

1. Entra como usuario normal de prueba y abre la URL de admin directamente. Debe rechazarte el servidor, no solo redirigirte la página.
2. Con ese mismo usuario, repite una petición que hace el panel (cópiala de la pestaña Network). Tiene que fallar.
3. Busca en el código del frontend service_role, sb_secret_ y supabaseAdmin. Ninguno debería aparecer en código que cargue el navegador.
4. Revisa dónde está guardado el rol e intenta cambiarlo desde la cuenta normal (editando tu propio perfil). No debe quedar guardado.
5. Entra como admin sin segundo factor. Si funciona, hazlo obligatorio.

Respuestas rápidas

¿Basta con una URL de admin secreta? No. Las URL se filtran en el historial, los registros y las capturas. El acceso se verifica en cada petición.

¿Puedo hacer el panel como una app aparte? Sí, y puede ser buena idea, pero aplican las mismas reglas: roles verificados en el servidor y ninguna clave secreta en su código del navegador.

¿Y usar Supabase Studio para tareas de admin? El acceso al panel de Supabase es muy poderoso. Limita quién lo tiene, usa cuentas individuales con doble factor y no lo tomes como reemplazo de un panel propio para personal no técnico.

¿El rol se actualiza al instante cuando lo cambio? Con app_metadata, solo cuando se renueva el token del usuario. Usa una tabla de roles si necesitas quitar acceso al momento.

¿Quieres que alguien lo revise?

El chequeo de salud gratis muestra lo que queda expuesto desde afuera; nuestra revisión de seguridad de Supabase recorre en el código los roles, las políticas y las acciones de admin, y también puedes contarnos cómo lo tienes armado.